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ABSTRACT 


U.S. Navy organizations have implemented disparate Command and Control (C2) 
visualization methods for each surface combatant platform class. As a result, infonnation 
uncertainty is introduced and the overall decision making process is impeded for the 
mission. A common architecture could resolve some of the aforementioned 
unsatisfactory aspects of the current situation and could also result in cost reductions. 
This report applied a disciplined systems engineering process to design a Command and 
Control Unified Architecture (C2UniArch) with focus on enhanced understanding and 
visualization of infonnation. Functional analysis and modeling tools were used to 
validate and create estimations about performance for the As-Is systems as well as the 
alternatives that met feasibility constraints. An assessment was made on candidate 
architectures’ performance and training benefits. The report was successful in 
demonstrating the benefits of a C2UniArch as quantified by the architecture analysis 
which met stakeholder and mission requirements. 
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EXECUTIVE SUMMARY 


Effective Command and Control (C2) is a basic requirement for the successful 
conduct of military missions and functions in the entire spectrum of military operations. 
C2 must be understood as more than a commander issuing orders; it encompasses many 
complex interacting elements. The inherent complexity of C2, combined with attempts to 
keep up with advancing technology, has led to a variety of C2 systems. This in turn has 
made the C2 environment more complex since each system does not do all that is 
required. Specifically, traditional visualization capabilities have not been adapted to deal 
with the complexities associated with most U.S. Navy needs, nor have they been 
designed to perform multiple related tasks while ensuring continuity of C2 functions 
supporting the mission. 

The disparity of C2 systems increases the amount of operator training needed, and 
has an adverse effect on the operators’ overall efficiency in performing their duties. The 
impact of disparate training results in greater operations and support costs without 
distinguishable improvements in overall C2 operational efficiency. 

Making faster, more accurate decisions will greatly increase the effectiveness of 
C2 and the commander’s ability to advance his objectives. Facilitating decision making 
is believed to be one of the best ways to speed up C2. By performing better sense 
making and presenting information clearly in a single comprehensive operational picture, 
the commander will be able to make prompt and accurate decisions. Through research 
and analysis, the actions necessary to achieve these objectives were revealed to consist of 
four major functions: Collect Information, Support Sensemaking, Plan, and Command. 

Therefore, the purpose of this report is to enhance sense making and the context 
of the operational picture used on surface combatants (cruisers, destroyer, and frigates) 
by providing a standardized C2 architecture enabling common visualization. A 
disciplined systems engineering approach was used in order to identify requirements and 
design an architecture for a system that presents an understandable, organized, consistent, 
and focused operational picture. 
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Through the systems engineering process, stakeholders were consulted and 
research was conducted. Once the problem was better defined, a functional hierarchy 
was created. More specific functional and non-functional requirements were generated. 
Upon completion of the functional hierarchy, alternatives were generated, screened, and 
refined. These alternatives were then evaluated based on three key perfonnance 
parameters: the time to make a decision, decision quality, decision error, the amount the 
new system would reduce training cost was also considered as an added benefit. 

Modeling and simulation tools were used to evaluate the perfonnance of the three 
key parameters. Vitech’s CORE and Rockwell Automation's Arena were used to 
simulate the functions of the alternatives. Using the CORE software program ensured 
modeling of both function and data flows of each alternative. The behavior model within 
the CORE software also enabled evaluation and validation of the architecture throughout 
the design process. Using the Arena software helped quantity timing and assessed the 
effects of varying inputs on each of the architectures. 

The three alternatives evaluated were the As-Is, the Hybrid, and the Global 
Understanding Network (GUN). The As-Is is an evaluation of what is currently being 
used; numerous stove piped systems presenting their own view of the world. The Hybrid 
system takes some of the information from current C2 systems and organizes and 
displays it in a single display. The Hybrid also retains some of the current architecture 
which has not been incorporated into the display methodology. The GUN replaces the 
various C2 systems with a more robust system where information is sorted categorically. 
This information can then be analyzed collaboratively by multiple operators. The 
information is once again shown on a single customizable display. The analysis done on 
this infonnation can be shared with more context and understanding across the Global 
Information Grid. 

The three alternatives have been evaluated on the time to make a decision, the 
probability of decision error, the quality of decision, as well as the resulting reduction of 
training required. Performance analysis results were not as expected, with only nominal 
gains for the evaluated measures overall. This was due to the focus of the models on the 
Support Sensemaking function, specifically Provide Common Visualization. Future 



models should include the remaining functions and may provide more definitive 
performance gains. Estimates in reduced training hours for the newer alternatives were 
substantial. Therefore based on the gains that were discovered and the potential 
reduction in training hours, the recommendation is for the U.S. Navy to move forward 
researching the GUN system. 
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I. INTRODUCTION 


The design, production, and implementation of tightly integrated shipboard 
systems, optimized to perform a specific function, has given rise to disparate and 
duplicative naval platform Command and Control (C2) system implementations. There is 
a belief that a common C2 architecture with a standardized system approach to 
visualization will aid war fighters in battling uncertainty during operations. As a result of 
this approach, there is potentially added benefit, resulting in cost reduction of training 
and life cycle support. 

A. BACKGROUND 

Command and Control is a core piece of naval warfare in which decision making 
takes place and orders are generated, monitored, and guided. The goal of C2 is to 
advance the commander’s plan leading to mission success. With that in mind, a C2 
system should support the commander’s intent associated with planning, directing, 
coordinating, and controlling the accomplishment of combat and other missions [JP 1- 
02], Another goal of C2 is to be faster than the enemy in decision and execution; the next 
decision and action needs to be executing while the enemy is still reacting to the previous 
activity [NDP 6, Command and Control]. 

To accomplish the goals of C2 an issue surfaces because there is not a universal 
Command and Control system within the U.S. Navy. C2 is comprised of a number of 
disparate systems with each C2 system focusing on a unique aspect of the mission. There 
is no set of common requirements driving these multiple systems. Incongruent systems 
have led to a shipboard Combat Information Center (CIC) filled with visualization and 
decision aids with diverse graphical interfaces, semantics, and processes. A simple 
example of this would be the installation of Global Command and Control System - 
Maritime (GCCS-M), LINK-16 Tactical Display Processor and the AEGIS Display, 
which are installed as complete systems. 

An important aspect of the disparate systems is that each system incorporates a 
visualization strategy that meets the narrow focus of that system. In the C2 environment 
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where operators and command staff must work with multiple systems to gain an 
understanding of the operational picture, this adds to the work load. Precious time is used 
to re-acquaint while moving from system to system. 

This carries over to the training the operator receives for proficiency in the 
systems as overlap and redundant training results from trying to understand the same data 
on different systems. Each of the systems, based upon their architectures, requires 
training pipelines for both operators and support personnel at different levels of 
difficulty. Considering the multitude of systems, training, configuration management and 
sustainment costs for the U.S. Navy can be very significant. 

This project concentrates on the decision making and visualization aspects of C2. 
This area was selected because while researching C2 it was found that improving 
decision making through visualization would meet most of our stakeholder’s objectives 
while minimizing effort required. 

B. PROBLEM STATEMENT 

U.S. Navy (USN) organizations have implemented many disparate systems to 
address different operational concepts, mission foci, and to introduce capability. Systems 
such as GCCS-M, Link-16 Tactical Display Processor, and AEGIS Display have 
overlapping functions of C2. They all present multiple visualization strategies for 
establishing situational awareness and decision making. 

USN C2 decision making quality, accuracy, and timeliness are being negatively 
impacted by the implementation of disparate systems which execute overlapping C2 
functions. This implementation has also resulted in high training costs. The focus of this 
paper is to analyze the current As-Is state and to investigate a common C2 Architecture 
which alleviates these issues creating a common streamlined presentation of information. 
Research questions that will guide research and analysis in this paper are: 

• What are the functions of C2 at the surface combatant level? 
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• What architectures can be defined that address common requirements of 
USN C2 decision making, specifically related to visualization? 

• Can decision making quality, accuracy, and timeliness be quantified and 
modeled within unified C2 architectures? 

• Does a unified C2 architecture improve decision quality, accuracy, and 
timeliness? 

• Does a unified C2 architecture reduce training costs? 

Answering these questions will make the different aspects of the problem become clear 
and allow a conclusion to be drawn. 


C. PROJECT GOALS AND DELIVERABLES 

The goal of this project is to analyze the current visualization elements of the U.S. 
Navy C2 architecture on the surface combatant platfonn and as they relate to decision 
and sensemaking. Furthermore, it performs research and develops unified architectures 
that combine the disparate C2 visualization strategies and improve U.S. Navy C2 
elements of decision and sensemaking. Finally, it provides analysis on decision quality, 
accuracy, and timeliness to examine if unified architectures improve USN C2 decision 
and sensemaking requirements. 

This report documents the C2 functional hierarchy with emphasis on sensemaking 
and, more specifically, contextualization. This report also documents an in depth 
analysis of the As-Is state and two new architectures that improve decision quality, 
accuracy, and timeliness. 

D. ASSUMPTIONS AND CONSTRAINTS 

This paper examines alternate architectures for Command and Control systems 
with a focus on visualization with the goal of reducing decision making time and 
uncertainty. This paper will only examine the aspects of C2 which directly affect the 
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decision making process. All other aspects of C2 supporting the same stakeholder need 
have been left for later study. 

The ship classes being considered are U.S. Navy surface combat ships excluding 
carriers. Two mission threads were considered Search and Rescue and Cruise Missile 
Defense. These were used to help define the alternate architectures and define 
performance measures. 


E. SYSTEM ENGINEERING AND DESIGN PROCESS 
1. Overview 

The tailored System Engineering Design Process (SEDP) applied for this project 
used an iterative design approach composed of three phases: Problem Definition, Design 
and Analysis, and Architecture Analysis. It was the primary means used to define the C2 
requirements and desired architectural baseline required by the U.S. Navy. An 
examination of the waterfall, classic Vee, and spiral system engineering processes were 
conducted to detennine the best approach for this problem [Blanchard and Fabrycky, 
2006]. It was detennined that a modified SEDP process as shown in Figure 1, derived 
from Sage & Armstrong’s’ Life Cycle of System Engineering, and the United States 
Military Academy (USMA) system engineering process, was the best approach [Sage and 
Armstrong, 2000]. These processes were combined in order to highlight the key ideas 
from Sage and Annstrong and also emphasize some important DoD methodologies used 
by USMA. The architecture analysis phase was modified to show architectural analysis 
recommendations have been made but a Life Cycle Cost Estimate has not been 
completed. 
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C2UniArch SEDP Process 



Figure 1. Tailored SEDP Diagram 

The tailored systems engineering design process developed by the C2UniArch team combined 
processes from USMA and Sage & Armstrong’s life cycle of system engineering. 

2. Problem Definition Phase 

This phase was an iterative process allowing Stakeholders’ objectives to be 
refined into a well-defined problem. The Problem Definition phase helped narrow down 
a loosely defined problem statement into a well-understood problem meeting 
stakeholders’ needs. The output of this phase was a clearly defined problem statement 
that was used to generate requirements. 

a. Needs Analysis 

The Needs Analysis is essential in determining the true nature of the problem 
along with the desired outcomes of the problem’s solution. Due to C2 being a complex 
and intricate domain a great deal of research was needed along with numerous 
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conversations with our stakeholders from the warfighter community. Research and 
discussion removed the layers of obscurity surrounding the initial problem statement 
allowing it to be transformed from wants into stakeholder requirements and an effective 
need. Also, in this section the system context including system inputs and outputs were 
identified. 


b. Functional Analysis and Decomposition 

Upon completion of the stakeholder analysis, a functional analysis and 
decomposition were necessary to transform the functional, performance, interface and 
other needs that were identified into an organized and consistent hierarchy. Functional 
decomposition took the identified high-level functions of C2 and broke them down into 
more easily understood sub-functions. This broke the complex C2 problem space into 
more manageable sub-problems. Thus, this phase focused on answering the question, 
“What are the functions of C2 at the surface combatant level?” 

In this part of the SEDP functions were researched that aided in understanding the 
situation and creating awareness. This includes making connections between different 
data types and communicating these connections effectively to various personnel. 


c. Value System Design 

The Value System Design started with the stake holder objectives being examined 
in parallel with the functional and non-functional hierarchies. This is done in order to 
further link the problem to the stakeholders’ objectives and determine the value of each 
design element. Evaluation measures were then identified. Key evaluation measures 
were then selected from those identified. These evaluation measures needed to be 
quantifiable and extractable during modeling in order to be used for evaluation of 
alternatives. 
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3. Design and Analysis Phase 

a. Alternatives Generation 

Alternative architectures were created to assess the impact of commonality of 
information display on C2 performed on surface combatants. Using the list of evaluation 
measures from the Value System Design, research was conducted to determine if 
alternative architectures existed which met system requirements. Candidate alternatives 
which were deemed feasible were selected for further analysis. The output of this phase 
was two architectures selected for further analysis through modeling and simulation. 


b. Model Alternatives 

The selected architectures were modeled. Simulations were built using ARENA 
simulation software for the proposed architectures to aid in the decision making process. 
The simulations yielded quantifiable results which allowed the value of each alternative 
to be objectively assessed. The data yielded was to measure each alternative in terms of 
its performance against the chosen evaluation measures. 


4. Architecture Analysis Phase 

a. Analysis of Alternatives 

In this segment, the alternative architectures were examined against the each other 
and the As-Is architecture. The input to this section was the results of the modeling and 
simulation along with additional information available on the proposed architectures. A 
variety of analyses were conducted using the modeling and simulation results to create a 
true mock up of the alternatives. During this phase, other benefits were examined which 
were more indirect in nature including those associated with the logistical aspects of the 
architecture. The output of this section provided in-depth results that help lead to a 
recommended architecture. 
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b. Architecture Analysis Recommendation 
As a culmination of the analysis performed in the previous phases, the 
Architecture Analysis Recommendation step provided quantified data on the alternative 
system architectures. After summarizing the analyzed data, this step presented a 
recommendation on how to proceed. The main purpose was to recommend how the 
problem is best solved based on the information found and analyzed. 
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II. PROBLEM DEFINITION 

The initial phase of the Systems Engineering and Design Process (SEDP) known 
as Problem Definition is the exploration of the original problem statement. This phase is 
an iterative process to ensure all aspects of the problem were identified, understood, and 
agreed upon by all stakeholders before entering the Design and Analysis Phase, the 
second phase of SEDP. This phase was comprised of two iterative steps: Needs Analysis 
and Value System Design. Two additional tools aiding in problem definition were used, 
functional decomposition and flow analysis. The final output of the problem definition 
phase was an understanding of the problem in the form of clear and unambiguous 
requirements meeting stakeholder objectives. To ensure clarity, the problem was then 
articulated in the form of a refined engineering problem statement. 

A. NEEDS ANALYSIS 

The first step in this phase was the Needs Analysis, which involved the use of 
various tools for identifying and outlining the system under study; the relevant 
stakeholders; and the stakeholders’ needs, objectives, requirements, and constraints. The 
products from the needs analysis are a list of system objectives as stated by the 
stakeholders and a functional decomposition. The goal of needs analysis was to 
transform the primitive need stated by the stakeholder into an effective need to be used in 
the next stage. 

The primitive need was understood to be: 

The [U.S.] Navy’s Command and Control (C2) strategy does not have a common set 
of C2 requirements that can be used across multiple surface ship platforms. There is 
a need to define a common set of C2 requirements to support the creation of a 
common enterprise level C2 architecture while considering emerging service-oriented 
architecture technologies. 

1. Background and Context of Maritime C2 

Conducting background analysis and establishing context of maritime C2 assisted 
in the understanding of the system. It provided a look at the system in tenns of its 
interactions with other systems and the environment, inputs and outputs, and overall 
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operation. From understanding the system in this perspective, deficiencies were 
identified and the gap between the current state of the system and the desired end state of 
the system were made clear. This was an iterative process further defining the system on 
each pass to eliminate the identified deficiencies and achieve proper interfaces. 

Understanding the problem required stepping back and examining the definition 
of C2 and determining if it could be the basis of the overall requirement. The definition 
of C2 from Joint Publication 1-02 is: 

The exercise of authority and direction by a properly designated commander over 
assigned and attached forces in the accomplishment of the mission. Command and 
control functions are performed through an arrangement of personnel, equipment, 
communications, facilities, and procedures employed by a commander in 
planning, directing, coordinating, and controlling forces and operations in the 
accomplishment of the mission [JP 1-02], 

This definition established a foundation for exploring and providing a basic idea 
of how C2 should be executed. This highlighted the system must be able to support the 
direction and coordination of a military effort. But it did not clarify if this also applied to 
all platforms, including surface combatants. It was further discovered C2 is a complex 
subject and not well understood by many. 

To add to this perspective, C2 was not limited to military organizations and 
involves thinking, sensing, responding, organizing, and monitoring also, and 
therefore was composed largely of activities in the cognitive and social domains 
[Alberts et al., 2001]. 

The complexity of C2 and all of its definitions has exacerbated the ability to 
create systems that support surface combatant commanders. Classic surface platforms 
were built with systems that were unitary in supporting well-defined combat mission 
tasks. Missions such as Anti-Submarine Warfare, Anti-Air Warfare and Anti-Surface 
Warfare have been tightly coupled into a surface combatant system. The C2 Systems, 
Applications & Afloat Networks resource sponsor, OPNAV N6F2, asserted that 
expectations have expanded to include missions that are not well defined and may 
include wartime and peacetime operations [Beck, 2009]. This has resulted in the need to 
access information from varying sources in many formats. A recent example was the U.S. 
Navy's efforts to improve the nation's Maritime Domain Awareness (MDA), which was 
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deemed critical in the global war on terrorism. Also, the Automatic Identification System 
(AIS) was mandated by international law for ships with Gross Tonnage of 300 or more 
tons [Department of Homeland Security, 2006]. AIS is a shipboard display and broadcast 
system. It is used by maritime activities and provides a means for ships to electronically 
exchange ship data, including identification, position, course, speed, port of departure, 
destination and supposed cargo [Department of Homeland Security, 2006]. Upon 
implementation of AIS, legacy U.S. Navy systems struggled to obtain and display this 
data [Klich, 2008]. 

Research revealed concerns about the ability of the war fighter to properly 
interpret the vast amounts of data being exposed. Infonnation is key to lowering 
uncertainty and is critical to effective decision making. Therefore, advanced techniques 
for supporting the military commander and displaying complex tactical situational data in 
a clear way must be analyzed. A part of C2 is the output and presentation of tactical 
information. It has a large influence on the general decision making process because the 
commander’s mental model of the battle space situation is based upon the information 
received and how information is perceived [Miller and Shattuck, 2004]. C2 is not just a 
process of putting seemingly unrelated items on a map. 

2. Stakeholder Analysis 

Nuseibeh and Easterbrook define stakeholders as “individuals or organizations 
who stand to gain or lose from the success or failure of a system” [Nuseibeh and 
Easterbrook, 2000]. To ensure the quality and comprehensiveness of system design, it 
was important to identify all relevant stakeholders and include them throughout the 
design process. The stakeholder analysis enabled a collaborative cooperation between the 
team and those individuals who were able to articulate what was required by the system 
and the performance expectations thereof. 

The resource sponsor, Office of the Chief of Naval Operations (OPNAV), is 
responsible for a collection of resources that comprise inputs to warfare and supporting 
warfare tasks by planning and identifying the funding for the requirements. A common 
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C2 architecture provides a potential savings in overall budget profde by reducing 
individual specific C2 designs. The Program Sponsor is yet to be determined, as it 
depends on program initiation. 

The execution agents and systems commands would be responsible for the 
development and acquisition of the architectural baseline and establishing the life cycle 
support of the system to be fielded. Representatives from the Program Executive Office 
Command, Control, Communications, Computers, and Intelligence (PEO C4I) and Space 
and Naval Warfare (SPAWAR) Systems Command were used to provide feedback on the 
architectural soundness, maintainability, and supportability of the design. Program 
Executive Office Integrated Warfare Systems (PEO IWS), which is responsible for 
surface ship and submarine combat systems, missiles, radars, guns, and electronic 
warfare systems, was also identified as a stakeholder. 

The war fighting community drives the requirements for the common C2 
architecture. Its tactical and operational experience is essential in providing data for this 
architecture. This in turn provides benefits to the war fighter, which enhances mission 
execution. To ensure this community interest has been taken into consideration, 
representatives from U.S. Naval Forces Pacific and Central Command, Joint Information 
Control Officers (JICO) were heavily consulted. The JICO is responsible for planning 
and management of the joint tactical data link network within a theater of operations and 
has unique insight to C2 expectations of the platform from the commanders’ level. Due 
to the nature of this problem, it was important this community’s interest was well 
understood. To enable a better understanding of this community’s perspective, C2 
analysts with prior war fighting experience were consulted. 

It was important to understand the perspective of each of the stakeholders. The 
analysis of existing documentation, such as organizational charts, doctrine, and manuals 
of existing systems was undertaken to get perspective on the stakeholder environment. 
Forward-thinking sources such as the Command Control Research Program (CCRP) were 
also researched. Semi-structured interviews were conducted and followed up with 
questionnaires shown in Appendix C. The questions that resulted from the research were 
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seen as a good way of starting a conversation with stakeholders. Stakeholders were 
consulted throughout the entire systems engineering process. 

a. Stakeholder Interviews 

The OPNAV representative confirmed the U.S Navy’s Command and Control 
strategy does not have a common set of C2 requirements used across multiple surface 
ship platforms. CAPT Rick Beck, from OPNAV N6F2, recognized the difficulty in 
quantifying a gain in force effectiveness achieved by Command and Control. Unlike a 
ship, a plane or a missile, how much C2 is needed to facilitate mission success is difficult 
to quantify. War fighter interviews revealed related concerns. CAPT Rick Beck further 
added, “one system design across multiple platforms should yield efficient training, 
configuration management and sustainment costs” [Beck, 2009]. CAPT Anderson, a 
battle watch captain from U.S. Naval Forces 5th Fleet, mentioned that it seemed logical 
the lack of a common architecture was possibly a contributing factor to a perceived lack 
of understanding of what C2 really provides [Anderson, 2009]. Finally, it was cited by 
the PACFLT N35 JICO that a common C2 architecture should enhance interoperability 
across different ship classes across the fleet. “Most DDGs and CGs fail to realize just 
how much they contribute to the C2 picture and ADM Willard’s goals” [Cetello, 2009]. 

b. Stakeholder Desired System Needs 

Through the stakeholder analysis, high-level qualitative system goals desired for a 
common C2 system were derived. It was important to understand and categorize the 
different types of requirements as they were captured from the stakeholders. Most 
important, the team needed to understand what the system was expected to accomplish 
within its environment. These were categorized and analyzed into functional 
requirements in the Functional Decomposition section. 

The below numbered list is the desired system objectives. The objectives 
highlighted in bold address stakeholder needs with regard to the situational awareness, 
system complexity, and decision support problems. These were used as a foundation for 
later functional analysis. 
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1. Provide the capability to gather information supporting mission objectives in a 
timely manner 

2. Provide the capability to assess the quality of the sensor and intelligence data 

3. Support the capability to interface with legacy local organic and national ISR 
sensors 

4. Provide for a cost effective approach for new interfaces 

5. Provide the capability to create a common understanding of the situation 
to include location, identity, status and intentions of friendly, hostile, 
neutral and non-military entities historically, currently, or planned 
reducing decision delays 

6. Provide the capability to display political and diplomatic information via 
a map interface 

7. Provide the capability to improve situational awareness by creating 
associations between different sources of data, if applicable 

8. Provide the capability to share information with Blue forces in near-real- 
time 

9. Provide the capability to alert on events that are geospatial or 
informational 

10. Provide the capability to display current and forecasted weather 
information 

11. Provide the capability to lay down objectives and work out alternative means 
for attaining them 

12. Reduce information assurance vulnerabilities 
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13. Provide the capability to maintain situational awareness in a disconnected or 
electronically denied environment 

14. System interface should be intuitive and interface should reduce 
operation complexity 

3. Environment Definition 

a. Surface Combatant 

Surface combatants include cruisers, destroyers, and frigates. They are primarily 
designed to fight in the open ocean in one of three warfare areas: anti-surface, anti¬ 
subsurface, and anti-air. Modem surface combatants are all equipped with sensors and 
engagement elements which enable appropriate action in all warfare areas. The 
definition includes other vessels, such as the littoral combat ship and the battleships of 
yesteryear. Aircraft carriers, amphibious ships, and some smaller vessels, such as mine- 
warfare ships and patrol craft, are not included in this study [Congressional Budget 
Study, 2009], 

b. System Environment 

The environment where the system will be installed includes the CIC, the bridge, 
staff spaces, and intelligence spaces. These environments are well maintained and away 
from the harsher elements that would be a consideration for systems directly exposed to 
the exterior of the ship or other spaces indirectly exposed such as engineering or the 
hanger bay. 

Despite the expected environment as described above, the system still needs to 
meet specific military shipboard requirements to be combat ready. Consideration for 
shock, vibration, interference, grounding, and power must be given. For the remainder of 
the report, it is assumed that any alternative can be designed to these standards. 
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c. Organizational Structure 

Surface combatants’ capabilities make them well suited for a variety of force 
structure mixes. The multi-mission packages, and the sheer number of CGs, DDGs, 
FFGs, and soon the DD(x), enable the U.S Navy to utilize the platforms in most tactical 
force structure packages. As depicted in Figure 2, the surface combatant can be used in 
the following compilations supporting the Joint Force Maritime Component Commander 
(JFMCC) operational cell called the Maritime Operations Center (MOC): Carrier Strike 
Groups (CSG), Expeditionary Strike Group (ESG), Coalition Operations, and Surface 
Action Groups (SAG) [NNWC Tacmemo 3-32-06]. All of the tiers of organizational 
structure benefit from a C2 architecture. The Commanding Officers and operators from 
each platfonn directly benefit from the local C2 system and exercise it tactically. Not 
only is the Surface Combatant C2 architecture a fundamental aspect of shipboard 
operations, the output contributes to the organization knowledge of the battle-space at 
higher levels. 


“Commanders then must compare their situation awareness and 
assessments of what is required to advance the plan with the actions of their subordinate 
commanders and act—remembering always that their goal is to contribute information 
and perspective that are not already evidenced” [Willard, 2002]. 


Surface Combatant Hierarchy 



Tactical 


Figure 2. Surface Combatant Hierarchy 

The naval Surface Combatant Hierarchy includes the Maritime Operations Center and its tactical 
structures, such as Carrier Strike Groups, Expeditionary Strike Groups, Surface Strike Groups, 
Coalitions, and Surface Action Groups. 
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4. System Boundary 


Once the investigation of the environment was completed, it was necessary to put 
the system into context. Identifying the boundary of the system aided in the 
understanding of what the inputs, outputs, and controls were for the Common C2 
architecture. This is demonstrated in Figure 3. 



Figure 3. System in Context (A-l) 

The development of the system boundary diagram (A-l) aided in putting the C2UniArch system into 
context. The inputs of the Common C2 are raw data and mission tasking while the output can be a 
decision, direction, order, or authority. Controls which are geopolitical factors, doctrine, and 
CONOPS are shown on the top. 


The inputs, shown in Figure 3, are very important because they start the C2 
function and get transfonned into the output. External interfaces to the system are Joint 
Systems, Users, Sensors, Communications, and the Enviromnent. The system interacts 
with DoD Joint Systems in tenns of relevant data and information exchange to supporting 
surface combatant missions. The Users interact with the system by providing the current 
mission and applying doctrine. Sensors provide data. Communications provides a path to 
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receive and transmit information and is relevant to mission success. The fundamental 
output of the system is an order, decision to take action, or communicated intent via a 
plan to engagement elements. This output may be a decision or communication to do 
nothing. Frictions in this case would represent feedback into the system if the orders did 
not execute according to plan. With respect to the environment, the system does not 
necessarily interact with it; however, the system is impacted or limited by the 
environment. 

To summarize the Needs Analysis segment of the Problem Definition, the team 
was able to identify the nature of the problem. Navy organizations have introduced 
unique approaches to expose new information sources leading to disparate processing and 
presenting of the information needed. Research revealed complication and confusion 
about what Command and Control is and how it can be accomplished. The complexity of 
C2 and disparate architectures combined, potentially impact situational awareness and 
cause delays in the decision making process. These issues were discovered as not only 
present across surface combatant classes, but within the platfonn itself. 

The effective need is used to guide the identification and examination of various 
components needed to establish metrics to measure successful completion of the report. It 
was created through iteration, vision and feedback during the processes utilizing 
Stakeholder Analysis, and problem examination. 

It was initially proposed that a common C2 architecture would be a solution to 
the unfavorable state. This paper examines if this is qualifiable and quantifiably accurate 
in the subsequent sections using the effective need as a guide. The effective need is stated 
below: 


“The U.S. Navy needs a flexible, reliable, easier to learn, surface combatant C2 
architecture that supports communication, storage and display of relevant, information to 
commanders to facilitate efficient understanding and effective decisions for mission 
accomplishment ” 
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The extent of the capstone project was assessed, and an understanding that all of 
the aspects of C2 would be difficult to cover. As a result, with stakeholder agreement, 
boundaries were established for this study to focus only on the decision making aspects 
of C2. Meeting with stakeholders, aided in identifying top level needs, which were drawn 
upon during the Functional Analysis and Decomposition stage. 

B. FUNCTIONAL ANALYSIS AND DECOMPOSITION 

Once the problem was understood, stakeholders interviewed and needs 
articulated, a functional analysis was perfonned to understand the potential architecture 
from a functional perspective. This approach allows for the architecture to be designed 
independently of any specific solution. A functional decomposition provides reasons for 
the different alternative components selected to implement the architecture. Analysis of 
the system in functional terms provides a foundation for developing original alternatives 
[Sage and Armstrong, 2000]. 

In order to start the functional analysis, examination of what the system needs to 
accomplish was conducted. This generated the basic question, “what are the functions of 
C2 at the surface combatant level?” To answer this question, a simplistic process model 
of C2 was needed, creating a framework and supporting the effective need. 

Research has shown Boyd’s OODA (Observe-Orient-Decide-Act) loop is clearly 
the dominant model of C2 and has morphed into various interpretations of the kill chain 
[Boyd, 1987]. Basically, the models all use the basic approach described in Figure 4. 
Fundamentally, these functions support planning, directing, coordinating, and controlling 
the accomplishment of combat and other missions. 
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Figure 4. Boyd’s OODA Loop 

A representation of the flow of the OODA loop is shown here. The flow of the OODA loop model 
applies to the combat operations process |Boyd, 1987]. 

The complexity of C2, and the problem as described by the stakeholders, forced 
the evaluation and consideration of not just what C2 was, but should be. Brehmer claims 
the OODA loop was too basic for today’s warfare. Brehmer adds the OODA loop does 
not include a representation of the environment and the affects of the decisions, arguing 
uncertainty and delays need to be taken into account, making the loop more dynamic. A 
more advanced interpretation was the Dynamic OODA loop, depicted in Figure 5, or 
DOODA loop, and specifies three different needed functions: data collection, 
sensemaking, and planning. Incorporating these effects into the loop constitutes a 
fundamental shift in focus from the traditional conception of C2 as “inward looking and 
concerned with handling the force (as embodied in definitions of C2), to a conception of 
C2 as outward looking and being concerned with achieving effects” [Brehmer, 2005]. 
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Figure 5. Brehmer’s DOODA Loop 

The dynamic OODA Loop. The modification to the OODA loop addresses the dynamic elements that 
influence the model. The items in black are functions that are logical relations that establish 
preconditions for the next function. The box highlighted contain the three fundamental function used 
from the loop |From Brehmer, 2007]. 

The DOODA loop decision making process model was determined best 
suited to create a framework to meet the effective need. The unified C2 architecture 
synthesized three fundamental functions from this model for surface combatants: Collect 
Information, Support Sensemaking, and Plan, to support the overall system objectives. A 
Command function was added to represent the order and military activity portion of the 
model. Figure 7 represents the high-level surface combatant C2 system internal functions 
needed to support stakeholder objectives. The inputs, outputs, and controls are the same 
as shown in A-l in Figure 3. 

Figure 6 shows the transformation of the OODA loop into the C2 
functions examined in this report. The left depicts the OODA loop. Next in the center, 
the DOODA loop is displayed with some additional annotations. The center shows a box 
around Planning, Sensemaking and Data collection, and another box around Order. The 
box around Planning, Sensemaking and Data Collection is to show that these functions 
came from Observe, Orient and Act from the OODA loop. Additionally in this paper, 
these functions make up the bulk of the C2 Functions which are Collect Information, 
Support Sensemking, and Plan. The box around Order is labeled Act. This is to point out 
that Act from the OODA loop has been partially absorbed into Order in the DOODA 
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loop, however part of Act is now a part of Military activity in the DOODA loop. In 
Figure 6, when transitioning from the DOODA loop to the C2 functions on the far right, 
Act and Order are not present. The functionality represented by these functions is 
replaced by Command. The rest of the DOODA loop including Military activity, 
Frictions, Effects, and Sensors are recognized as important functions and are still 
considered part of the battle space but are not considered Command and Control 
functions. 


r ^ 

v 4CT j 


OODA 



Collect 

Information 


Support 

Sensemaking 


Plan 


Command 


C2 Functionality 


Figure 6. Transition of the functions of C2 

Analysis of the traditional models enabled synthesis of the core functions of Command and 
Control. Starting with the OODA loop, exploring the enhancements of a more advanced DOODA 
loop established four fundamental functions needed. 
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Figure 7. IDEF AO Functional Representation of the C2 System 

Further decomposition of AO shows four essential functions required for a Common C2. These four 
functions are Collect Information, Support Sensemaking, Plan, and Command. Interactions of these 
functions transform data and information into a decision. 

1. Collect Information 

The function Collect Information must not be confused with the Observe portion 
of the OODA loop for the C2UniArch. Collecting information has multiple tasks. As 
shown in Figure 7, Collect Information, derived from Data Collection in the DOODA 
loop, illustrates that data collection is to provide a point for raw data from sensors and 
information to flow into the system and does not include the sensors but may include the 
tasking of sensor resources. The outputs of sensor systems are raw data. This raw data 
provides the input for the data collection portion of the DOODA loop. The Collect 
Information function for the common C2 system defines information transfer 
requirements for effective decision making and supports the sensemaking function. This 
does not include the sensors themselves or represent the monitoring or localizing of any 
targets. This function’s purpose is to obtain data from any available sensor or data service 
relevant to the mission being conducted. Because of the vast amounts of data from 
sensor information, national and human intelligence, weather, Joint information, and 
various forms of report from subordinates, the function must be able to allow the decision 
maker to tailor or filter infonnation to cope with data overload. The downside in this 
approach is “it is not obvious to the decision maker which data have been excluded by the 
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individual’s preferences. In addition, individuals may have different preferences selected, 
resulting in “divergent and possibly confusing views of the environment” [Shattuck and 
Miller, 2004]. Understanding this drawback, the function allows the decision maker to 
subscribe to the data needed for the mission and provides an alert if data is available to 
meet some desired criteria. To support the objective, this function stores historical or 
planned target data for future analysis. Stored data allows for the ability to maintain state 
in the event the platform was disconnected from its communication path or it was being 
electronically denied. The output of this function would feed the data requested to the 
Sensemaking function. The system needs stated from the stakeholders map to the collect 
information function are listed in Table 1. 


Function 

System Objectives 

Collect 

Information 

Provide the capability to gather information supporting mission objectives in 
a timely manner 

Provide the capability to assess the quality of the data 

Support the capability to interface with legacy local organic and national ISR 
sensors 

Provide the capability to maintain SA in a disconnected or electronically 
denied environment 


Table 1. Collect Information Function Objectives 

The Collect information function is part of the C2 system and supports the sensemaking function. Its 
objectives come from the stakeholder requirements to include the ability to assess the quality of data, 
maintain SA, and create a common understanding of the situation. 

2. Support Sensemaking 

Sensemaking is defined as a function with the aim of producing an understanding 
of the mission in terms of what needs to be done to accomplish the mission [Weick, 
1995]. This function aids the decision makers in making sense of the information and the 
situation. It involves many phases of knowledge processing of which the majority is 
cognitive. This function is at the core of the problems stated from our stakeholders and is 
key to addressing situational awareness issues. This concept was best summarized by 
Perla, “it’s knowing what’s going on so you can figure out what to do” [Perla et ah, 
2000 ]. 
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Theorists suggest the ability to make a decision by lowering uncertainty can 
somehow be ensured in warfare by adding more data via sensors [Owens, 2000], In 
addition, an increase in the quantity of data offers no advantages if the quality of data has 
been compromised. The Support Sensemaking function recognizes that an increase in 
information may increase ambiguity. If this ambiguity is not properly addressed, it may 
impede the decision making process. In the 1973 Yom Kippur War, the failure of Israeli 
intelligence to foresee the Egyptian and Syrian attacks was not due to a lack of 
information but to the misunderstanding of the information available in the context of an 
inappropriate shared awareness of Arab intentions [Bolia, 2004], 


In order to address the issues mentioned and meet system objectives, the 
following section will focus on this function and will be further decomposed. The system 
needs stated from the stakeholders map to the support sensemaking function are listed in 
Table 2. 


Function 

System Objectives 

Support Sensemaking 

Provide the capability to create a common understanding of the situation to include 
location, identity, status and intentions of friendly, hostile, neutral and non-military 
entities historically, currently, or planned reducing decision delays 

Provide the capability to display political and diplomatic information via a map 
interface 

Provide the capability to improve situational awareness by creating associations 
between different sources of data, if applicable 

Provide the capability to share information with BLUE and Coalition units in near-real- 
time. 

Provide the capability to alert on events that are geospatial or informational. 

Provide the capability to display current and forecasted weather information 

System interface should be intuitive and interface should reduce operation complexity 


Table 2. Support Sensemaking Function and Objectives 


The Support Sensemaking function is the core of the issues stated from the stakeholders and is the 
key to addressing SA issues. The objectives are aimed to aid the decision maker to try to make sense 
of the information and situation through many phases of knowledge processing. 


A functional hierarchy of the Common C2 in Figure 8 shows the Support 
Sensemaking function and its sub functions. The sensemaking function was central to 
addressing the decision making process and is key to transforming data into information 
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and supports understanding. The three sub functions of the Support Sensemaking 
function are Collate and Correlate, Provide Contextualization, and Share Information. 



Figure 8. Support Sensemaking Functional Representation 


The Support Sensemaking function is the key function identified from this study based on the 
stakeholders’ priority needs of Common C2 functions. It also shows how it relates to its sub 
functions which are Collate and Correlate, Provide Contextualization, and Share Information. The 
other functions were not decomposed because they did not directly impact the decision making 
phase. 


a. Collate and Correlate 

Decomposing Support Sensemaking yielded three functions and multiple sub¬ 
functions. Figure 9 displays the decomposition of Collate and Correlate. The Collate and 
Correlate function defines what must be done to the data once it is received. This function 
was broken down into two sub-functions: Organize Infonnation (Collate) and Link 
Related Items (Correlate), as represented below. 
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Figure 9. Collate and Correlate Functional Representation 

The Collate and Correlate function is where information is sorted, organized, linked, and associated. 
The output of this function is fed into the Provide Contextualization function, where the information 
is contextualized. 

The Organize Information (Collate) sub-function is where the received data is 
organized into operational and tactical information so decisions can be made. Once the 
information is organized accurately and concisely, the data is then compared to other 
critical elements of information so the decision maker can easily verily what he or she is 
observing. 

The next sub-function associated with the Collate and Correlate function is Link 
Related Items (Correlate). In the Link Related Items sub-function, information is 
screened for meaningful relationships, connections, and relevancy to aid the 
understanding and analysis of the decision maker. 

b. Provide Contextualization 

Provide Contextualization, shown in Figure 10, is the function that establishes a 
set of norms for the system and the operator that puts events in perspective of each other 
[Smith, 2005], This is a key function allowing the user to gain understanding of the data. 
Understanding requires a fusion of awareness and context to establish meaning. This 
requires integration of numerous elements of the situational picture that vary over time, 
establishing patterns matching expected behaviors [Marsh, 2000]. 

This function may also be commonly understood as a way to provide situational 
awareness. “Situation awareness was the perception of the elements in the environment 
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within a volume of time and space, the comprehension of their meaning, and the 
projection of their status in the near future” [Endsley, 1995]. This function is supported 
by three sub-functions: Establish Knowledge of the Battle Space, Provide Common 
Visualization, and Alert on Pattern or Anomaly. 



Figure 10. Provide Contextualization Function 

The Provide Contextualization function is also known as a means to provide SA. It is the key 
function that allows the user to gain understanding of the data. 

Establishing knowledge of the battle space is the function that recognizes “a 
decision maker’s knowledge of the environment can be no better than what has been 
detected by the sensors at any given point in time; understanding can be no better than the 
data they are able to access” [Shattuck and Miller, 2004]. The function is supported by 
several sub-functions to aid in gathering this knowledge. Analyzing Historical 
Information (A2211) is the sub-function that establishes the building block for 
deciphering complex scenarios, e.g., when and how often an event has happened before. 
Historical information can also be used as a feedback mechanism for analysis and assess 
ongoing cause and effect chains. 
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In order to support system objectives, Glean Intelligence (A2212) is needed to 
understand historic and current, planned, hostile, neutral or non-governmental agencies 
actions. Intelligence is the product resulting from the collection, processing, integration, 
analysis, evaluation, and interpretation of available information concerning foreign 
interests, including information and knowledge about an adversary obtained through 
observation, investigation, analysis, or understanding [JP 1-02], This function is to 
provide the commander with an accurate understanding of the threat situation as it relates 
to current and future operations. It does not include the acts of gathering intelligence; just 
a reaping of the data already gathered and analyzed supporting the mission at hand. 

Glean Environmental Information (A2213) is to support the objective to display 
any meteorological or oceanographic phenomenon that will impact sensor, weapon, or 
mission performance. 

The Establishing Mission Specific Associations function (A2214) is an important 
aspect to the contextualization function. This function establishes disparate elements or 
events that can be related to one another based upon observations over time. This 
function would allow the operator to create these relationships to aid establishing 
knowledge of the situation and to flag disparities for manual resolution of ambiguity. 
This may also include projections for future events. These relationships may be made 
between objects displayed and tasks or mission interests, for example, creating an 
association between a ship’s Area Of Responsibility (AOR), enemy range, and areas of 
strategic advantage for both friendly and enemy forces. 

The Provide Common Visualization function facilitates understanding of the 
current situation as well as the mission. It provides an effective method to present 
information and data to the user to support the sensemaking process. 

The Provide Common Visualization function is comprised of three sub-functions, 
the first of which is Tailor the Display (A2221). “The capability to tailor what is 
displayed is one way designers may attempt to assist decision makers in coping with data 
overload. The drawback in this approach is that it is not obvious to the decision maker 


29 



which data have been excluded by the individual’s preferences” [Shattuck and Miller, 
2004]. 


Providing Geospatial Reference (A2222) is the function that gives the operator 
and commander a point of reference. The most common interpretation of this function is 
a map with overlays to portray the battle space. However, other means of geospatial 
displays could be created. 

The final sub-function for common visualization is Provide Standard Ontology for 
Information (A2223). This function establishes the standards for the visualization 
elements. This function was added to address interoperability as a functional aspect of the 
system. "In stove-piped systems, semantics are in the mind of humans. Humans must 
resort to catalogs and other natural language documentation to interpret the meaning of 
system outputs, and must perform labor-intensive, manual transfonnation to interchange 
data between systems" [Laskey et. al, 2001], This function also ensures that when 
operators are viewing the system, there are familiar elements to the information being 
displayed. Textual information follows themes. Tracks or objects will display common 
attributes and follow a standard symbology and color scheme. Multiple sensor ontology 
combined in a single format can increase understanding of message content and provide 
commanders reference material for selecting the right platforms from which to retrieve 
data [Ceruti, 2004]. Common ontology can simplify training by establishing 
predictability of the user interface and can also aid in decreasing uncertainty of the 
decision maker. 

The Alert on Pattern or Anomaly (223) is a function with the purpose of aiding 
commanders in identifying any events of interest based upon some set criteria. Events 
could be based upon mission criteria or status of the systems in use. Preset rule-based 
criteria could be enabled to automatically recognize unusual patterns uncharacteristic of 
the nonn and inform watch-standers to unsafe, illegal, threatening, and other anomalous 
activities. The monitoring for patterns could be used both externally and internally, 
allowing the commander to recognize any conditions of the system that maybe undesired. 
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For example, communication paths that are down or being denied and or that the system 
has been compromised. 


c. Share Information 

Now that the infonnation has been collated, correlated, and contextualized, it can 
then be shared, established by its authoritative reporting responsibility, and 
communicated. Figure 11, depicts the Share Infonnation function, which is essentially the 
key function that defines making information available for coloration with participants 
(people, processes, or systems) [DoD Infonnation Sharing Executive, 2007]. Sharing 
information provides common mission awareness to all participants involved. 



Figure 11. Share Information Functional Representation 

Sharing information is the means by which participants communicate standardized information and 
establish a common situational awareness. Owners of the information (Authoritative R2) are 
required to keep the most up-to-date information for authorized participants. 


The Collaborate with Participants function (A231) is the function that establishes 
the cooperation of forces and resources to share available information in real time. This 
entails providing the methods of which information can be shared, whether it is by 
electronic or manual systems to inform participating organizations of the mission at hand. 
This also entails the establishment of the trust among reporting responsibilities, agencies, 
organizations, and more that require the “need to know” of specific information from 
their respective authoritative reporting responsibility. 
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The Establish Authoritative Reporting Responsibility function (A232) brings 
together the informational flow hierarchies. In these hierarchies, standardized 
information needs to flow up and down the chain of command [Alberts and Hayes, 2005]. 
This implies that the owner of specific mission information has the responsibility to 
maintain and share that information as deemed appropriate. Information owners have to 
be intelligent with respect to knowing what information is important to what participants, 
and in a circuit-based communications infrastructure, they also need to be quick to kn ow 
about how to reach them. This can be measured by the percent of how many participants 
are informed of the decision hierarchy. 

The Communicate Standardized Infonnation function (A233) is the method by 
which standardized information is communicated. Communication can be done by a 
variety of electronic sources and in many different formats 

3. Plan 

The planning function takes the output of Support Sensemaking function as input, 
and supplies the “how it should be done.” Research uncovered that planning itself is not 
just another function of C2. It is not just a specific plan. According to the US Forces 
Command’s, Adaptive Planning Concept of Operations, “planning includes the mutual 
understanding of the capabilities, limitations, and consequences of civilian and military 
actions and identifies ways in which military and nonmilitary capabilities best 
complement each other” [J9 Adaptive Planning Department, 2008], 

Planning is important to the overall aspect of C2 and enables detennining courses 
of actions (COAs), and finalizing with the promulgation. But in order to focus on 
decision making, further analysis will be left to future studies. 

4. Command 

The command function takes the planning output from the planning function and 
turns it into orders to be issued. This function would involve writing orders and 
transmitting them, as well as verifying their arrival and proper understanding by the 
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recipients. This function would also include monitoring the execution by means of 
feedback, at which the C2 process repeats itself via the frictions flow. This function is 
important to the overall C2 Process, but will not be dealt with any further to aid in 
focusing on the stakeholder issues. 

To reiterate, in order to properly address and bound the problem, further 
discussions will only trace to the sensemaking aspects of the system. 

C. FUNCTIONAL FLOW ANALYSIS 


Enhanced Functional Flow Block Diagrams (EFFBDs) have been used to show 
the functions and their order that the Common C2 needs to perform. EFFBD also 
displays the controls and the data flow. This functional analysis has been chosen to not 
only show the dynamics of the system, but to also allow for easier modeling of the data 
dependencies. The model developed using EFFBD will serve as the functional 
architecture for the Common C2, and it also helped examine each of the its functions and 
sub-functions. An EFFBD model for the Common C2 system has been developed using 
CORE. CORE is a systems engineering tool developed by Vitech Corporation and aides 
in requirements management, functional analysis, architecture development, and 
verification and validation. 

1. C2UniArch Functional Flow 

a. AO Provide Common C2 Functional Flow 

The Common C2 system has been decomposed into following four functions 
which are: Collect Information, Support Sensemaking, Plan, and Command. Figure 12 
shows the top level EFFBD for Common C2. This serves as the first layer of functional 
flow for the Common C2. 
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Figure 12. Provide Common C2 EFFBD 

The top level functions and their order of relationships with each other are essential in providing the 
necessary means to perform C2. The collection of information and making sense of it is crucial for 
the planning and the execution of decisions. 

EFFBD in Figure 12 demonstrates the sequential order of all the major functions 
of the Common C2. Each of the functions is triggered by the one preceding it. The 
Collect Information function fulfills the data collection and dissemination requirements. 
The data from Collect Information function is passed to the Support Sensemaking 
function. The Support Sensemaking function uses this data and puts it into perspective 
by producing understanding of the situation, and determining what needs to be done to 
accomplish the mission. The Plan function takes the output of the Support Sensemaking 
function and determines how the mission needs to be accomplished. Finally, the 
Command function is the final piece of the Common C2 system. It takes the output of 
the Plan function and provides the final authority for execution of the plan. 

Because of the narrowed scope this project, only Support Sensemaking function 
functional flow has been analyzed in more detail. Figure 13 depicts the IDEFO for 
Support Sensemaking function. This is the second layer of decomposition for the 
Common C2 architecture. 
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Figure 13. Support Sensemaking IDEFO 

The functional flow of the Support Sensemaking function consists of Collate and Correlate, Provide 
Contextualization, and Share Information sub functions. This IDEFO demonstrates the sequential 
nature of functions required to provide Support Sensemaking capability for the Common C2. 

Support Sensemaking function consists of three functions which are: Collate and 
Correlate, Provide Contextualization, and Share Information. The Collate and Correlate 
function creates associations between related data. The Provide Contextualization 
function provides context to the data or event. The Share Infonnation function provides 
collaboration, report and responsibility, and communication capability. 

b. A21 Collate and Correlate Functional Flow 

To further understand the sub functions of the Support Sensemaking function, the 
third layer of functional analysis for the Common C2 architecture was analyzed. The 
third layer of functional analysis shows the functional flow of Collate and Correlate, 
Provide Contextualization, and Share Information functions. The first function from this 
decomposition is the Collate and Correlate function. Figure 14 depicts the EFFBD for 
the Collate and Correlate function. 
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Figure 14. Collate and Correlate EFFBD 


The Collate and Correlate function consists of Organize Information, and Link Related Items sub 
functions. The Organize Information sub function is essential to collate data and information. The 
Link Related Items sub function is essential to make associations between data and information. 


The functional flow of Collate and Correlate function shows that the ambiguity 
among the data is reduced, information is organized, associations are created, and li nk s 
are created among similar data and events. 

c. A22 Provide Contextualization Functional Flow 

The next function in the third level of functional analysis is the Provide 
Contextualization function. Figure 15 shows the EFFBD for this function. The 
functional flow of Provide Contextualization function is unique because it demonstrates 
the concurrency in execution of Establish Knowledge of Battlespace, Alert on Pattern 
Anomaly, and Provide Common Visualization sub functions. The combined output of all 
these sub functions is what is passed out to the Share Infonnation function. 
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Figure 15. Provide Contextualization EFFBD 


The Provide Contextualization function consists of Establish Knowledge of Battlespace, Alert on 
Pattern Anomaly, and Provide Common Visualization sub functions. This EFFBD demonstrates the 
concurrency of these functions and that all of the pieces are necessary to share information. In the 
higher level EFFBD Alert is considered a part of the Situational Awareness/Assessment output. 


The EFFBD for Provide Contextualization function demonstrates the concurrency 
of the sub functions. Establish Knowledge of Battlespace, Alert on Pattern Anomaly, and 
Provide Common Visualization all occur in parallel. Because this paper is investigating 
the visualization aspect of Common C2, each of these sub functions will need to be 
decomposed for further analysis and understanding. This will result in the fourth layer of 
decomposition. Establish Knowledge of Battlespace, Alert on Pattern Anomaly, and 
Provide Common Visualization functions functional flow is shown in Figures 16, 17, and 
18 respectively. 

Alert on Pattern Anomaly generates the output Alert. Alert is shown in Figure 15 
to provide traceability to the lower level EFFBDs. However, it has been omitted from the 
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higher level EFFBDs because Alert is considered a part of the Situational 
Awareness/Assessment output. 



Figure 16. Establish Knowledge of Battlespace EFFBD 

The Provide Knowledge of Battlespace function consists of Analyze Historical Information, Glean 
Intelligence, Glean Environmental Information, and Establish Mission Specific Associations. All of 
these sub functions are necessary to analyze the situation with respect to the surroundings and 
establish a perspective. 

The Establish Knowledge of Battlespace function uses the historical, intelligence, 
and environmental data to establish perspective. This function consists of Analyze 
Historical Information, Glean Intelligence, Glean Environmental Information, and 
Establish Mission Specific Associations sub functions. As shown the functional flow in 
Figure 16, Analyze Historical Information, Glean Intelligence, and Glean Environmental 
Information functions have a parallel relationship and are in series with Establish Mission 
Specific Associations function. The parallel and series relationship can be explained by 
the fact that historical, intelligence, and environmental information are needed prior to 
creation of associations. 

Alert on Pattern Anomaly, contained in the fourth layer of functional analysis, is 
presented in Figure 17. 
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Figure 17. Alert on Pattern Anomaly EFFBD 

The Alert on Pattern Anomaly function consists of one output Alert. For the Common C2 system, it 
is essential to keep track of changes as it relates to data and information; therefore, generating alerts 
when there is an anomaly is essential. 

Alert on Pattern Anomaly function generates an Alert output. This function 
enables the system to stay updated as changes are detected. These changes could be a 
result of new alerts as they become available or existing alerts that are not relevant 
anymore. 

The Provide Common Visualization function, contained in the fourth layer of 
functional analysis, is presented in Figure 18. 
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Figure 18. Provide Common Visualization EFFBD 

The Provide Common Visualization function consists of Provide Common Ontology for Information, 
Provide Geospatial Reference, and Tailor Display sub functions. Common ontology for information 
and accurate geospatial reference are essential for the Common C2 system to effectively provide a 
standardized tailored display to the operators or decision makers. 

The Provide Common Visualization consists of the Provide Common Ontology 
for Infonnation, Provide Geospatial Reference, and Tailor Display sub functions. It 
provides common ontology for infonnation and geospatial reference. Its final output is a 
tailored display. This sub function concludes the Provide Contextualization function. 

d. A23 Share Information Functional Flow 

Going back to the third layer of functional analysis, Share Infonnation function is 
the next function following the Provide Contextualization function. It is the third sub 
function under the Support Sensemaking functional hierarchy. Figure 19 presents the 
EFFBD for the Share Infonnation function. 
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Figure 19. Share Information EFFBD 

The Share Information function consists of Collaborate with Participants, and Establish 
Authoritative R2, and Communicate Standardized Information sub functions. This function will 
enable the Common C2 system to effectively share information for all concerned groups. 

The Share Information function consists of Collaborate with Participants, 
Establish Authoritative Reporting and Responsibility (R2), and Communicate 
Standardized Information sub functions. This function is responsible for establishing 
reporting and responsibility authority and communication of the information. As shown 
the functional flow in Figure 19, Collaborate with Participants and Establish 
Authoritative R2 functions have a parallel relationship and are in series with 
Communicate Standardized Information function. The parallel and series relationship 
can be explained by the fact that collaboration, and reporting and responsibility tasks are 
needed prior to communication of the information in a standard format. 

2. Non-Functional Decomposition 

Upon decomposition of the functions and discussion with the stakeholders with 
regard to objectives, the team was able to capture desired attributes and characteristics of 
the target architecture. Functional analysis aided in identifying related objective 
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interactions among relevant elements of the problem and was categorized as non¬ 
functional requirements. 

The following are explanations utilized to aid in defining those characteristics. 
Figure 20 is a hierarchical depiction of the criteria that can be used to judge the operation 
of the architecture. 



Figure 20. Provide C2 Functional Decomposition 


These non-funetional requirements were decided from the stakeholder’s analysis as being the quality 
attributes desired of the C2 system. 


a. Provide Adaptability 

Provide adaptability was derived from the stakeholders’ need for a system that is 
highly adaptable for future upgrades. There is also a need to ensure that a C2 system can 
support interface changes without major impacts to the supporting the mission threads. 
Adaptability for this instance can be defined as the ability to change to fit new or special 
external or internal interfaces. Adaptability will be measure by compliance with agreed 
upon DoD recognized open or military standards. 
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b. Provide Interoperability 


Interoperability: The ability of systems, units, or forces to provide data, 
information, materiel, and services to and accept the same from other systems, units, or 
forces and to use the data, information, materiel, and services so exchanged to enable 
them to operate effectively together. National Security System (NSS) and Infonnation 
Technology System (ITS) interoperability includes both the technical exchange of 
information and the end-to-end operational effectiveness of that exchanged information 
as required for mission accomplishment [JCS 1-02], 

Provide Interoperability is a common DoD requirement and is derived from the 
requirement to cooperate and communicate between systems and platforms. 
Interoperability is defined above and is a measure of how much context and semantic 
continuity is maintained by the systems use of interfaces to other systems and the user 
graphical interface. The system is required to comply with DoDD 4630.5 and DoDI 
5000.2 interoperability guidance. 

c. Provide A vailability 

Operational Availability (A 0 ): The degree (expressed as a decimal between 0 and 
1, or the percentage equivalent) to which one can expect a piece of equipment or weapon 
system to work properly when it is required, that is, the percent of time the equipment or 
weapon system is available for use. A 0 represents system “uptime” and considers the 
effect of reliability, maintainability, and mean logistics delay time. Ao may be calculated 
by dividing Uptime by Total time. UP time is the time a system is operational between 
failures. DOWN time is the time the system is not operational that is, Ao = System Up 
Time / Total Time (Up Time + Down Time). It is the quantitative link between readiness 
objectives and supportability [CJCSI 3170.01F]. 

Provide Availability is important to the user because the measure of system 
effectiveness relates directly to the system hardware, software, support, and environment 
characteristics, which include Operational Availability (Ao) and Mean Time Between 
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Failure (MTBF) into one significant parameter. Through research of like systems and 
stakeholder interviews it was detennined the system needed to maintain an Ao of .98. 

d. Provide Reliability 

Provide Reliability was determined as the need to reduce the likelihood of failure. 
As per discussions with stakeholder the desired reliability of the system and availability 
will have the appropriate MTBF of no worse than the as-is state. 

e. Include Usability 

Include Usability is a supportability need the stakeholders’ expressed to ensure 
integration of requirements for the human into the system. Usability is defined as ease 
with which people can employ a particular functional aspect of the system and the ease of 
operation. System objectives as confirmed by the Surface Warfare Program Manager's 
Guide and the stakeholders are [Malone, 2001]: 

• Reduce the incidence and impact of human errors (the direct cause of 80% of ship 
accidents) 

• Enhance human performance, specifically situational awareness and decision 
making 

• Improve training and personnel management which can be measured by change in 
training time required 

f Reduce Vulnerability 

Vulnerability is the need to protect and defend information or weaknesses present 
in the architecture. Reduce vulnerability is the requirement of ensuring the system is able 
to be configured to meet and maintain minimum Infonnation Assurance (IA) Defense in 
depth standards, to include certification and accreditation IAW the DoD Information 
Technology Security Certification and Accreditation Process (DIACAP) [DoDI 5200.40]. 
The system is required to comply with a security posture IAW DoDD 8500.2 at a MAC 
level I. 
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D. PRELIMINARY REQUIREMENTS 


Stakeholders were involved in developing requirements and building an 
understanding of the problem. Elicitation resulted in the analysis of the system objectives 
and functional analysis. The summary of requirements in Table 3 trace from stakeholder 
desired system objectives to the system functions. To focus on the stakeholder problems, 
two areas were addressed: overall system objectives and requirements related to creating 
understanding, or sensemaking. The latter produced requirements resulting from 
decomposition of C2 and proper sensemaking vice explicitly stated stakeholder needs. 
These top level requirements were also essential for specifically addressing C2 
architecture problems. 

Once system functions were understood, the team was able to articulate the 
system specifications into clearly stated language. The following requirements are 
preliminary and have not been validated through fonnal DoD Joint Capabilities 
Integration and Development System (JCIDS) or Naval Net Warfare Command (NNWC) 
review. 


Unfortunately, many of the interface methods used by existing C2 sensemaking 
systems do not necessarily have good time-constrained behavior. There is also the 
recognition that data arrives from differing sources at various rates. Due to the large 
variations in data arrival rate times, data retrieval and sensemaking functions were not 
constrained to a specific time and will be needed as quickly as possible. 
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REF 

Function 

Requirement 

AO 

System Level 

System interface should be intuitive and system should reduce 
operation complexity by complying with MIL-STD-1472F 

Al.l 

Collect Information 

Maintain situational awareness state in a disconnected or 
electronically denied environment for a minimum of 24hrs 

A2.1 

Provide 

Sensemaking 

The systems shall reduce uncertainty by reducing ambiguity. 

All objects or tracks in the system shall be maintained and 
ambiguity reduced to less than 1% 

A2.2 

Provide 

Sensemaking 

The system shall provide for reduced reaction time by providing 
in-context, concise information presentations, and reduce 
average decision time, no worse than current systems, by timely 
presentation of mission-relevant and mission-critical 
information 

A2.3 

Provide 

Sensemaking 

The systems shall increase quality of information produced by 
ensuring data is complete. System shall increase average 
number of Friendly, Hostile, Neutral and Non-Military correctly 
identified over aggregated time. 

A223 

Provide Common 
Visualization 

Design and arrangement of displays and controls shall be 
consistent with the operator’s and maintainer’s tasks and actions 

A2232 

Provide Geospatial 
Reference 

The system shall be capable of representing the physical domain 
supporting existing geospatial formats. Requirements for 
Geospatial Information and Services shall meet CJCSI 

3901.01B 

A212 

Link Related Items 

System shall establish relationships among objects in terms of 
their identification, deployment, kinetic interaction, 
organization role, and type similarity with 99.9% accuracy 

A212 

Link Related Items 

Establish relationships between sensors and sensed entities as 
well as relationships between entities of interest and other 
entities with 99% accuracy 

A212 

Link Related Items 

Conceptual categorization and organization of data shall be 
made explicit to the operator for rapid detection and 
classification of a situation 

All 

Provide 

Contextualization 

The system shall provide the ability to view the past, present 
and predicted situation to include location, identity, status and 
intentions of Friendly, Hostile, Neutral and Non-Military 
entities historically, currently or planned. The user shall be able 
to view a prediction of the current situation into the future based 
on background knowledge about the dynamic of situation 
contingencies 

A221 

Establish 

Knowledge of 
Battlespace 

The system shall account for existence of elements of the 
situation and allow access to display elements to include 
intelligence relevant to mission, environmental information, and 
historical information. 
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A223 

Provide Common 
Visualization 

The system shall provide a flexible and adaptable mode of 
visualization and interaction that is independent of the data 
infrastructure. 

A2231 

Tailor Display 

The system shall be able to tailor display based upon user set 
criteria and support for user-driven selection of information 
sources 

A2233 

Provide Standard 
Ontology for 
Information 

The system shall make use of effective and consistent labels, 
symbols, colors, terms, acronyms, abbreviations, formats, and 
data fields by following MIT, STD 2525Bcl 

A2222 

Alert on Pattern 
Anomaly 

The system shall provide an indication via visual and audio 
(configurable) alert when elements do not match because values 
of a parameter are different, an event occurs that should not, or 
an event does not occur that was registered. 

A233 

Communicate 

Standardized 

Information 

The system shall provide shared situational awareness by 
minimizing average time to disseminate information (less than 1 
second from transmission) 


Table 3. System Functions and Requirements 

This table lists the system functions for the major sensemaking functional objectives and their 
respective requirements. 


E. VALUE SYSTEM DESIGN 

Once the system functions were developed and the requirements were understood 
and verified by stakeholders, the team utilized these to guide in defining measurable 
system performance. The need to improve Sensemaking to be more efficient and 
effective requires an examination of the overall C2 Architecture. This is not an exercise 
to re-design C2 but to evaluate the architecture, looking for ways to improve the decision 
making process. Value System Design (VSD) is used to identify the objectives, measures, 
and desired values to establish criteria, which will be used to determine how well a 
potential alternative may be evaluated to improve Sensemaking. This is done by 
decomposing the C2 functions into objectives and evaluation measures. 

1. Value System Modeling 

The Value System Model was developed as a qualitative method to organize the 
stakeholders’ functional objectives. This model provides a method to transform the 
stakeholders’ functional objectives into functional requirements. To measure how 
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effective the functional requirements are, quantitative measures are needed to determine 
if the C2 systems meet these requirements. These are captured as evaluation measures. 
Figure 21 represents the process model taking the stakeholders’ functional objectives and 
converting them to a well-defined requirement. Then criteria are determined to measure 
effectiveness and performance. 


Stakeholder 

Functional 

Objective 


Functional | 

Requirement 


I 


Measurement 

Of 

Effectiveness 


Evaluation 

Measures 




Measurement 

Of 

Performance 



J 


Figure 21. Value System Process Model 


This process model illustrates the progression from the Stakeholders Functional Objectives 
transformation to quantifiable evaluation measures. These evaluation measures will aid in 
determining how well the system is doing, and if the system is meeting stakeholder goals. 

2. Value Hierarchy 

The top-level Value Hierarchy for Support Sensemaking is shown in Figure 22. 
These functions are an aggregation of the resource sponsor inputs from interview and 
questionnaires. Once the stakeholders’ analysis was conducted the need to decompose 
Support Sensemaking was clear. 
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Figure 22. Support Sensemaking 


The Value Hierarchy of Support Sensemaking showing system functions is illustrated in this figure. 
It sets an order of importance of the sub-functions of Support Sensemaking into Collate and 
Correlate, Provide Contextualization, and Share information. 

3. Evaluation Measures 

Sensemaking has two objectives; the first is to reduce uncertainty and is measured 
by the probability of decision error (the lower the better). This objective captures how 
the system is reducing the amount of questionable data the users have to evaluate. Does 
the decision maker have all the required data they need to make a decision? The second 
objective is to decrease reaction time which is measured by the elapsed time from first 
receiving the data to making a decision (the lower the better). This objective captures 
how long it takes a decision maker to make a choice once the system has provided all 
requested data. 

A sub-function for Support Sensemaking is Provide Contextualization. This sub¬ 
function was targeted because of the objective to increase the quality of information 
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produced. This objective ties into the Support Sensemaking objective to reduce 
uncertainty by its evaluation measure information accuracy and completeness. The 
higher the ratio the better the quality of the decision made. 

Although not a part of Supporting Sensemaking function, training is another 
benefit as a part of this reports decision making analysis. The training function has two 
objectives, the first is decrease training hours and is measured by change in training time 
required (less is better). It is the position of this paper that with commonality particularly 
in the common visualization component would provide opportunities for cost savings in 
the way of reduced training time. One way to verify that a decrease in training hours has 
occurred is to measure the time required to train an alternative system versus the as-is 
system. The second objective for training is training efficiencies which is measured by 
change in training cost (lower is better). Training cost can be related or tied to the 
amount of hours trained. So if the amount of hours decrease from the as-is system due to 
efficiencies provided by the alternative system, training cost will tend to decrease as a 
result. Table 4 shows the key evaluation measures, their objectives, and associated C2 
functions. A more complete list of evaluation measures for Support Sensemaking is in 
Appendix D of this report. 
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REF 

Function 

Objective 

Evaluation Measure 

A2.1 

Sensemaking 

Reduce uncertainty 

Number of failures in making a decision 
within an allotted time and number of 
total decisions, (less is better) 

A2.2 

Sensemaking 

Decrease reaction time 

Average elapsed time for decision, (less is 
better) 

A2.3 

Sensemaking 

Increase quality of 
information produced 

Average number of data elements that 
enhance the decision above what is 
required, (less is better) 

A21.1 

Collate 

Increase situational 

awareness 

Percentage of accurately identifying 
critical elements properly, (greater is 
better) 

A213.1 

Correlate 

Increase information 
clarity 

Number of data elements in unambiguous 
state, (lower is better) 

A22.1 

C ontextualization 

Increase quality of 
information produced 

Information accuracy and completeness, 
(more is better) 

A222.1 

Common 

Visualization 

Improve geospatial 
Information 

Maximize geospatial accuracy (mean of 
positional accuracy), (less is better) 

A223.1 

Standard 

Ontology 

Decrease Training and 
reaction time by 
maximizing use of 
standards 

Compliance of information displayed 
using proper standard:(MIL STD 

2525Bcl). (less is better) 

A23.1 

Share 

Improve Timeliness of 
information 

Minimize Average Time to disseminate, 
(less is better) 


Training 

Decrease training 
overlap and redundancy 

Change in training time required, (less is 
better) 






Table 4. Key Evaluation Measures 

The key (highlighted) evaluation measures were the focus of evaluation the C2 As-Is system along 
with the alternatives. 


The Introduction and Problem Definition section addressed the primary question, 
“what are the functions of C2 at the surface combatant level?” These sections identified 
the main C2 functions as Collect Information, Support Sensemaking, Plan, and 
Command. The Support Sensemaking function was the focus of this paper and was 
decomposed into Collate and Correlate, Provide Contextualization, and Share 
Information sub-functions. Each sub-function was decomposed additional levels as 
necessary until the respective sub-function objective addressed a requirement, or partial 
requirement, and suitable measures of effectiveness were established. 
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III. DESIGN & ANALYSIS 


A. ALTERNATIVES GENERATION 

The first step of the alternatives generation process included brainstorming for 
technology and existing systems that satisfied, or could be modified to satisfy the Support 
Sensemaking’s functions and requirements. Support Sensemaking is made up of the 
functions Collate and Correlate, Provide Contextualization, and Share Information. The 
second step was to build on the brainstorming results and fit potential solutions together 
as alternatives, ensuring the defined sub-functions were all satisfied by each alternative. 
This yielded four complete alternatives to be further analyzed. 

For the final step, four alternatives were analyzed in a feasibility screening. Two 
were selected for a more detailed comparison against the As-Is architecture. A detailed 
description of the remaining alternatives is provided later in this report. The descriptions 
below show how these alternatives’ functions support a common visualization 
methodology, which presents all available C2 data in a well-organized and uniform way. 

1. Development of Alternatives 

Uncertainty can cause delays in decision making with respect to Command and 
Control. The goal is to make the decision making aspect of C2 faster, increase decision 
quality, and decrease decision error. In order to improve sensemaking and facilitate 
decision making, the Support Sensemaking functions have been analyzed. 

The functional analysis and decomposition of the Support Sensemaking function 
produced Collate and Correlate, Provide Contextualization, and Share Information sub 
functions. These primary functions were carried forward into the Zwicky’s 
Morphological process. In this process, several brainstonning exercises produced 
alternatives that satisfy and achieve the results that these sub functions were intended to 
achieve. In addition, how Support Sensemaking’s primary functions could be executed 
was researched via the web, interviewing stakeholders, and examining how similar 
functions are performed in other systems. Some examples of sources consulted are 
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Defense Technical Information Center (DTIC), research perfonned on Berndt Brehmer’s 
works, news websites, and various DoD publications. Shifts in DoD design philosophies 
were also considered, for example, the desire for Service Oriented Architectures (SOAs). 

Following the brainstorming exercises and research, these alternatives were 
organized in the Zwicky’s Morphological Box which is shown in Appendix B. From the 
Zwicky’s Morphological Box, the alternatives for each of the sub functions were 
combined to form new architecture alternatives. The only architecture alternatives that 
were considered for further study and analysis are displayed in Table 5. Other 
architecture alternatives that did not appear to be feasible were discarded. 


Alternatives - Support Sensemaking 

Alternative Name 

Collate and 
Correlate 

Provide Contextualization 

Share Information 

The Hybrid 

Unique Interface 
Correlation Server 
(UICS) 

Mixed Legacy (ADS) and New 
Standardized and Customizable 
Visualization 

Use of Legacy 
(TADIL or CEC) and 
New Real-time Data 
Distribution Service 

Global 

Understanding 
Network (GUN) 

Service Adapter 

New Standardized and Customizable 
Visualization 

Real-time Data 
Distribution Service 

3-D Display 

Common 

Computing 

Correlates 

Three Dimensional Display only (e.g., 
Google Earth) 

Use of Legacy 
(TADIL or CEC) 

Holographic 

Walkthrough 

Environment 

Quantum 

Computing 

Holographic Imaging 

Updated to share new 
data 


Table 5. Alternatives Table 

Results from the alternative generation provided four alternatives that support sensemaking. The 
As-Is provides the baseline for the newer alternatives. 
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Table 5 shows how Support Sensemaking’s functions have been addressed by the 
candidate architectures. A brief description of alternative architectures is presented next. 
Each description includes how the alternative addresses Support Sensemaking’s 
functions. 

2. Brief Alternatives Description 

Hybrid architecture alternative - This architecture modifies the As-Is 
architecture’s Collate and Correlate and Provide Contextualization functions. The 
Hybrid architecture introduces a Unique Interface Correlation Server (UICS), which 
takes the data and infonnation from all of the processing systems of the As-Is architecture 
for the Collate and Correlate function. The Hybrid architecture performs the Provide 
Contextualization function through a single, user-customizable display, where all of the 
available mission critical infonnation is made available to the user and decision maker. 

GUN architecture alternative - This architecture differs from the Hybrid 
architecture’s Collate and Correlate, Provide Contextualization, and Share Information 
functions, however, there are many similarities between the Hybrid and GUN 
architectures. The GUN utilizes service adapters that take all the data and infonnation 
from the processing systems and converts them into universal fonnats. The converted 
data is then used to perform the Collate and Correlate function. After correlation checks 
are complete, the data is available to the users and decision makers. The users and 
decision makers can tailor this infonnation for their specific requirement on a single 
display, thus performing the Provide Contextualization function. The Share Information 
function is performed by a real-time data distribution service which allows the 
information to be shared with remote allies. 

3-Dimensional Display alternative - For the Collate and Correlate function a 
Common Computing Correlator would be used similar to the Hybrid alternative’s UICS. 
Similar to the GUN, a single customizable display would be used in order to Provide 
Contextualization. This display would be a 3-Dimensional holographic display to 
enhance the visualization of the operational picture [AIST, 2006]. This allows the user to 
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see the operational picture from all angles. This alternative makes use of currently 
available technology to perform the Share Information function. 


Holographic Walkthrough Environment alternative - Quantum computing 
brings together information using information theory, computer science, and quantum 
physics [Steane, A, 1998]. This encompasses using specific theorems, error correcting 
codes, correlations, key distributions, quantum algorithms and more to treat information 
in a variety of ways. This allows information to process much more quickly in support of 
collation, correlation, a holographic environment, and infonnation sharing. The 
Holographic Walkthrough Environment is an enclosed room in which objects and people 
are projected by a holographic display system; this audio-visual platform adds the ability 
to support real-time collaborative and 3-D interaction between geographically distributed 
war fighters. This enhances both the Provide Contextualization and Share Information 
functions. 

In the next step of the system engineering process, a feasibility screening was 
conducted in order to determine which alternatives were best suited to continue with 
further evaluation. 

B. FEASIBILITY SCREENING 

Four criteria were selected for a feasibility screening. The criteria are 
Technological, Physical, Operational, and Financial. Each of the alternatives has been 
evaluated against the criteria. The alternatives that have failed to meet the criteria have 
been considered a “no go” and have been eliminated from further analysis. The two 
alternatives that have been selected for further analysis are the Hybrid and GUN. 
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1. Criteria Selection 


The following criteria were selected to evaluate the proposed alternatives. A 
detailed description of each criterion is given below along with what will cause an 
alternative to be deemed a failure in that category. 

Technical Feasibility: To receive a passing grade, there is an expectation that this 
alternative will be available in a reasonable time-frame. The alternative will receive a 
failing grade if the technology, while feasible, will not be available in ten years. Ten 
years were chosen as being a reasonable time-frame at the current pace of technology 
evolution unless there is an unforeseen breakthrough that dramatically reduces the time to 
move from a laboratory into a production environment. 

Operational Feasibility: To receive a passing grade the alternative is expected to 
reduce uncertainty and provide a richer straight forward operational picture. If it is not 
likely that the alternative will create a better operational picture and thereby reduce 
decision uncertainty, it will receive a failing grade. 

Physical and Environmental Feasibility: To receive a passing grade, the 
alternative is expected to function normally in the intended surroundings. If the 
alternative is not likely to function normally in the intended surroundings, then a failing 
grade is assigned. Because this system is expected to operate on a ship, attention must be 
paid to SWaP (size, weight, and power requirements). Extraordinarily large systems may 
weigh too much, consume too much power or have cooling requirements that could be 
unattainable within the confines of the allotted spaces. The system must also be able to 
pass shock and vibration requirements. 

Cost Feasibility: To receive a passing grade, the alternative costs are expected to 
be in-line with other programs of equal complexity. This includes any large expenditure 
for new technology development. If the alternative costs are expected to be significantly 
larger than similarly complex programs, a failing grade will be assigned. An alternative 
must cost no more than twice the cost of refreshing the As-Is architecture. In the next 
section, each of the alternatives has been judged by these criteria. Those that failed in 
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any one of these categories have been eliminated as a possible alternative. Those that 
have passed the screening moved to alternative scoring and cost analysis. 


2. Screening 

Each of the proposed alternatives has been evaluated against the selected criteria. 
A simple pass or fail was given to each alternative. Table 6 displays the results. 


Requirements and 
Constraint 

Alternatives 

Hybrid 

GUN 

3DD 

Holographic 

Walkthrough 

Environment 

Technical 

Pass 

Pass 

Fail 

Fail 

Physical and 
Environmental 

Pass 

Pass 

Pass 

Fail 

Operational 

Pass 

Pass 

Pass 

Pass 

Cost 

Pass 

Pass 

Fail 

Fail 

RECAP 

Pass 

Pass 

Fail 

Fail 


Table 6. Feasibility Screening 

Each alternative was evaluated against the specified criteria for feasibility. A fail was given to the 
alternatives that did not pass all of the criteria. 

The Holographic Walkthrough Environment alternative failed the feasibility 
screening. It is technologically infeasible at this point. Development costs would be 
excessive in an attempt to create a workable holographic walkthrough; it has also failed 
in the Cost category. It has also failed in the Environmental category because the ships 
being considered have a very limited amount of space. The idea of the Holographic 
Walkthrough is to provide a large room which you can walk though and interact with the 
items displayed. It is simply too large to be put on the platforms being considered. 

The 3DD has also failed. It has failed in the Costs and Technical categories. 
Although preliminary development has begun on such a display, unless there is a 
technology breakthrough, a substantial development investment must be made before the 
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technology is ready to depict the operational environment at the necessary level of detail. 
The technology currently does not address any particular operational requirement. 

Both the Hybrid system and the Global Understanding Network system have 
passed and will be examined in the next section. Both these alternatives meet the 
fundamental functions of sensemaking, however what makes them different is how they 
fulfill the functions. A detailed description of these systems along with the As-Is is 
explained in the next section. 

C. DETAILED ALTERNATIVES DESCRIPTION 

1. As-Is Description 

On the typical naval surface combatant platfonn, in this case the Ticonderoga 
class cruiser and Arleigh Burke class destroyer, the CIC includes multiple C2 systems 
that accomplish the Collate and Correlate, Provide Contextualization, and Share 
Information functions. The typical location of the C2 display systems in the CIC are 
depicted in Figure 23. The various systems are represented by shading and mapped to its 
typical location. The asterisk marks future C2 display systems that are slated to be added 
to the CIC. 
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Figure 23. Typical Display Consoles in CIC 

This is a layout of the combat information center aboard a typical Ticonderoga class cruiser. C2 
systems and components, which are used in the CIC, are identified including future systems that will 
soon be added. [Picture from Military.com] 

The systems comprising the current As-Is architecture perfonn some of the same 
functions. For example, the Tactical Tomahawk Weapon Control System (TTWCS) is a 
system that collects and correlates information, provides a visual display, and shares 
information. A second system that can accomplish these functions is the Naval Fires 
Control System (NFCS) which also displays the Common Operational Picture (COP) and 
streamlines the decision-making process. A third example where these functions can also 
be accomplished is the AEGIS Display System (ADS). The ADS console provides a 
capability so AEGIS operators can clearly view large-screen displays. The Command 
and Control Processor (C2P) is a message distribution system designed to control and 
manage the interfaces between the three tactical data li nk s (Link-4A, Link-11, and Link- 
16) and the operator. 

A final system that is part of the As-Is solution is the Global Command and 
Control System-Maritime (GCCS-M). This system satisfies the functions of Support 
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Sensemaking. GCCS-M fuses, correlates, filters, maintains, and displays location and 
attribute information on friendly, hostile, and neutral land, sea, and air forces. It 
integrates this data with available intelligence and environmental information in support 
of command decision-making. The user can use the data to construct tactical pictures 
using maps, charts, topography overlays, oceanographic overlays, meteorological 
overlays, imagery data, and intelligence information coordinated into a Common 
Operational Picture (COP) which can be shared locally or with other sites. Figure 24 is 
one display of many the modern version can provide. 



Figure 24. GCCS-M 4.X Display 

This is a screenshot from a GCCS-M console. Maps are used with overlays to provide an operational 
picture to analysts in the CIC. [This Graphic was taken from Command and Control Programs, 
PMW150, GCCS-M Fleet Introduction Brief] 

Many of these display consoles provide the means to visualize and interpret 
various kinds of data such as a map of objects, symbols, and track information. This 
information is provided to the commander for his decision making process. Figure 25 
represents the worst case of how disparate systems have overwhelmed the environment 
for the operator doing C2 functions. The operator has to continually scan the various 
displays, each with different display methodology, as well as be attentive to auditory 
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stimulus. Not only are there various display types, most have their own associated input 
device such as a keyboard and mouse. 



Figure 25. Multiple C2 Systems Displays 


The larger picture depicts the overwhelming number of displays an operator can be asked to look at 
while doing his job. The smaller pictures show some of the types of disparate displays the operator 
could be looking at in the larger picture. 


The point of naming all of these systems is to show C2 is currently supported in a 
large number of different ways. The idea here is: one needs to understand the 
information provided in all of these displays to perfonn good C2. To put it another way, 
Command and Control is currently performed by operators looking at many different 
systems, some of which were listed above, to gain an understanding of the operational 
picture. This understanding is then shared with the commander to proceed with the next 
C2 function Plan. A simplified graphical representation of these individual stove piped 
systems is shown in Figure 26. Each system provides the Collate and Correlate, Provide 
Contextualization, and Share Information functionality. Although the figure indicates 
distinct data sources, in reality each system may be accessing some of the same data and 
displaying the information in a unique way. 
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Figure 26. As-Is Design 


This figure illustrates the current As-Is state. System A, B, through Z, represent the large number of 
different systems. Each system has its own sensors or data sources or both. These systems have 
individual processing systems and accompanying displays, in the CIC. 


No single system in the As-Is architecture commonly addresses the Support 
Sensemaking sub functions Collate and Correlate, Provide Contextualization, and Share 
Information but rather these functions have been addressed in an ad hoc way by various 
systems. It is important to understand how these functions are addressed. Currently each 
system, with its own specific mission, Collates and Correlates its own information from 
data streams that are important to its specific mission and Provides Contextualization by 
presenting the information to the users by utilizing proprietary displays. This report 
considers Provide Contextualization of the As-Is architecture to include the user gaining 
an understanding from each of the relevant stove piped systems with C2 elements. Each 
system is responsible for sharing its own information. For example, Aegis Weapon 
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System (AWS) uses Cooperative Engagement Capability (CEC) and Tactical Digital 
Information Link (TADIL A and J). Also, non-tactical information sharing is done via 
chat and Common Operational Picture synchronization tools. So, although in many cases 
a commander may have used various systems in order to gain an understanding of the 
operational picture, this deeper understanding is unable to be shared effectively. 


2. Hybrid 

The Hybrid architecture, shown in Figure 27, expands and modifies the current 
architecture in the areas of data and information storage, display methodology, and how 
the infonnation is shared. 



Figure 27. Hybrid Design 

The graphic illustrates how the Hybrid system takes the information provided from the sensors and 
processing systems in the As-Is architecture, combines, and sorts this information. This data can be 
viewed on a single display. However, each system will also be able to maintain an independent 
display when their unique view is deemed mission critical. In this graphic, System Z represents a 
legacy system that will maintain its current display due to complexity or need. 
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The first major aspect of this alternative is the Unique Interface Correlation 
Server (UICS) and the associated unique Interface Processors for each interface. Each 
Interface Processor accepts the data from interfaces such as data links, sensors, etc., and 
converts it into standardized data fonnats. The Interface Processors add an additional 
layer at the interface level but this reduces system complexity later by using standard data 
formats instead of proprietary data formats. 

The UICS accepts the standardized data from various Interface Processors, and 
organizes the mission relevant data into clear and concise format (collate). During the 
collation, redundant data or data conflicts are tagged for later review and de-confliction. 
The UICS will also link the data (correlate) to create meaningful relationships. 

The assembled data is analyzed and mission specific associations are created then 
monitored to enhance operational assessment of the infonnation as a whole. The 
information is available on operational displays as well as for collaboration with other 
operators. 

As the data and information are processed and monitored, the operators may 
configure alerts to be generated based on mission parameters or pattern changes. The 
alerts may be mission specific or global across multiple mission scenarios. 
Contextualization provides for a common visualization which affords customizable views 
allowing the operators to focus on mission specific data. A geospatial reference is 
generated for accurate positional orientation and the data is set to a standard ontology. 
The displays are tailored to display only relevant information based on user set criteria. 
The new Provide Contextualization function is capable of linking data from all the 
relevant C2 systems and a unified view is achieved. 

The key is there are now fewer displays that need to be consulted in order to get 
an understanding of the operational picture. This is designed to make it easier for the 
analyst to form a clear operational picture quickly. This view of the operational picture 
can then be shared with the commander by showing him a reduced number of 
information streams, which make it easier to understand, and allows him to quickly move 
on to the C2 Planning function. 
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The Hybrid system utilizes a mixed approach for the Share Information function. 
Each individual system’s capability to share information will need to be leveraged. Either 
CEC or LINK could be used to maintain interoperability with legacy platforms and 
include a new standardized real-time data distribution service. 


3. Global Understanding Network (GUN) 


The Global Understanding Network solution, shown in Figure 28, expands and 
modifies the Hybrid architecture in the areas of data and information storage. 




Figure 28. GUN Design 

The GUN takes all of the data sources of disparate systems and makes all of this information 
available on each operator’s display. This means the displays are fully customizable to allow the user 
to see any information that has been collected clearly. 

This solution replaces the unique UICS of the Hybrid solution with service 

adapters. The service adapters are used to put all the data into universal formats. This 

data is then stored and organized by its type. This completes the Collate and Correlate 

function in a unified way. The utilization of adaptors and the standardization of services 
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align this alternative closer to the Services Oriented Architecture (SOA) model. SOA is a 
design model based on reuse, scalability and interoperability. The service adaptors 
remove the point-to-point stove pipe connections of the legacy systems. 

In the GUN design, all of the information collected is available on a single 
universal display that connects directly to a standardized and organized data repository. 
This allows the operator to customize their views displaying any subset of the data 
collected. All the infonnation collected is available to each operator and they can 
customize their views to allow fast access to all the information that is relevant to them. 
Also, this setup allows views to be saved to the data repository and shared with other 
analysts. For collaboration, areas on each display can be marked for sharing, allowing it 
to be viewed on other displays by other operators who may need the information. 
Provide Contextualization is thereby completed with all available data not just data 
present in one C2 systems sphere of influence. 

The GUN also provides for an open standardized way to Share Infonnation. The 
customized view created by the Collate and Correlate function and modified by the user 
in the Provide Contextualization function can be shared globally with others. This is 
where this architecture received its name. The understanding that has been created by the 
system and tailored by the operator is now available on the Global Understanding 
Network. 

Through alternatives generation and feasibility screening, three architectures have 
been defined that answer the second research question, “What architectures can be 
defined that address common requirements of USN C2 decision making, specifically 
related to visualization?” The three C2 architectures were the As-Is, the Hybrid, and the 
GUN. The AS-IS architecture defines the current visualization methods with a variety of 
displays showing different data or the same data different ways. Two new architectures 
focus on C2 with an emphasis on improving C2 through visualization by providing 
common visualization techniques and concepts, either in part as with the Hybrid or as a 
complete solution as with the GUN. 
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D. MODELING AND ANALYSIS 

Modeling of the information flow was used in detennining which of the feasible 
alternatives is recommended for further analysis. Modeling and analysis focused on the 
visualization aspect of the Support Sensemaking function, how it affects information 
flow, and ultimately decision making. Modeling and analysis was performed on the three 
alternatives determined by the feasibility screening as part of the tailored SEDP. These 
three alternatives are: As-Is, Hybrid, and Global Understanding Network (GUN). 

1. Modeling Approach 

The modeling approach was to model cognitive aspects of C2 with an objective to 
measure and compare the three alternatives. An encountered challenge was the 
comparison of non-existent alternatives, Hybrid and GUN, to the existing alternative, As- 
Is. Because data was limited or does not exist for these non-existent alternatives, the 
following approach was used to effectively evaluate the performance of these non¬ 
existent alternatives. 

Creating a notional model for the As-Is and running a simulation to obtain values 
for the key performance parameters established a baseline. This model served as a 
template and was also used to model the other alternatives. Only the information flow 
was altered for each alternative. The established baseline was used to compare the 
performance of the new, non-existent alternatives. The key perfonnance parameters 
included were the ones directly addressing the timeliness and decision factors associated 
with the current operational requirements. The performance data from each simulation 
was recorded and used in the comparison of the alternatives. The results from the 
simulation were compared against related MOEs and further analyzed. Table 7 shows the 
selected items from Table 4 used in the model. Not all MOEs were considered during 
evaluation; the most important MOEs considered were the ones that directly impact the 
response timeliness and the accuracy of decisions. 
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REF 

Function 

Objective 

Evaluation Measure 

A2.1 

Sensemaking 

Reduce uncertainty 

Number of failures in making a decision within 
an allotted time / Number of total decisions. 

(less is better) 

A2.2 

Sensemaking 

Decrease reaction time 

Average elapsed time for decision (secs), (less 
is better) 

A2.3 

Sensemaking 

Increase quality of 
information produced 

Average number of data elements that enhance 
the decision above what is required, (less is 
better) 


Table 7. Selected Measures of Effectiveness from Evaluation Measures 

These measures were selected for the models due to their relevance to the timeliness and accuracy of 
the decision making process. 


2. Arena Model Description 

Rockwell Automation’s Arena was chosen as the tool to create the models and 
run the simulations. Arena was selected because of its flow chart based approach in 
constructing models. This kind of approach is well suited for modeling of information 
flow and allowed for measures to be taken at chosen locations in the C2 architectures. A 
storyboard of the model is shown in Figure 29. 
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Figure 29. Graphical Representation of the As-Is Model 

In the As-Is architecture, numerous operators receive and interpret information from multiple 
sensors and data sources. The differences in visualization systems require users to reacquaint 
themselves when moving between displays possibly causing delays. 


In order to make a decision, key pieces of infonnation are required based on the 
situation. Ten data elements representing information needed to make a decision were 
used to model the As-Is. This number was chosen after evaluating the mission threads 
discussed earlier in this report and determined to be adequate for a notional model. These 
data types were randomized with a unifonn distribution and had a random arrival rate 
with an exponential distribution with a three second mean. Data types were routed to 
specific systems in front of one of three operators. Each operator had four consoles to 
operate. Since the operator had multiple interfaces, a value was calculated relative to the 
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distance between the system the operator was on and the system he or she was moving to. 
This value represented the cost in time for repositioning and re-acquaintance with the 
other system. 

The operator passed, or relayed, the infonnation to the Tactical Action Officer 
(TAO) if needed. The relaying of infonnation prevented the operator from handling 
other incoming information at his workstation once the relay started until it was 
complete. Similarly, another operator could not pass infonnation to the TAO if he was 
busy talking with another operator. Think of this as preventing multiple operators from 
yelling infonnation to the TAO at the same time making the infonnation unintelligible. 
Updates to perishable data were accounted for by randomly routing half of the data 
elements already held by the TAO to him as updates to existing infonnation. This 
construct is consistent with behavior observed during similar command and control field 
experiments where information was passed to a decision maker [Shattuck and Miller, 
2007]. 


This process repeated until either all required pieces of information were obtained 
or until a specified time value expired indicating the mission required a decision despite 
not being optimal. This threshold was obtained from doctrine during the mission thread 
analysis. Decision quality was measured on how many of the ten data types were 
included in the TAO’s decision making process. Decision error was detennined if time 
expired to make a decision and not all required data elements were present or if an 
expired data element was processed. 

The models for the other alternatives, Hybrid and GUN, functioned identically but 
the flow of infonnation was changed to represent their respective architectures. The 
model for the Hybrid had two consoles per operator versus the four in the baseline. The 
operator in this alternative was still handling the same information but only had to switch 
between two displays. The model for the GUN had a single unified display per operator 
with all the information flowing to it. This approach ensured the captured data was 
isolating the objective of the models. 
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The concept of modeling infonnation flow related to C2 on-board a surface 
combatant is complex due to the many permutations required to actually represent all 
scenarios possibly encountered. The model was purposefully isolated on the notional 
operator handling of information related to multiple interfaces and not made to represent 
an actual CIC. The model does not accurately reflect the number of operators in the 
expected environment, the actual number of sensors on-board ship and the respective data 
output, or variation in operator behavior such as alertness or distraction. These 
conditions could be areas of future modeling efforts if deemed necessary however were 
considered unnecessary and potentially convoluting to the model’s results. 

3. Data Elements 

Data elements for the model were decided upon and held constant for all three 
simulations. Only the flow of information was changed to represent the different 
alternatives. These data elements held constant for each alternative were: arrival rate of 
data elements, the number of data elements contributing to making a decision, the data 
elements required to make an accurate decision, the time involved for an operator to 
switch from one workstation to another, the time required to relay information to the 
decision maker, the maximum time before infonnation expired, and the maximum time 
allotted to make a decision. Table 8 contains a description for each data requirement. 

Data elements for the analysis were decided upon prior to constructing the model 
and appropriate data recording mechanisms were employed to collect data. The data 
collected for analysis was: time to make a decision, number of decision data elements 
used in the decision, number of decisions made, and number of decision errors. The 
collected data was used to detennine average time to make a decision, decision quality, 
and probability of decision error. 
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Data elements (model input) 

Value 

Raw information arrival rate 

Exponential distribution (3 seconds) 

Number of data elements in mission 
thread 

10 

Number of required data elements 

5 

Time to switch between consoles 

Normal distribution (mean: 2 x number of consoles 
changed, standard deviation: 1.5) in seconds 

Time to relay information to TAO 

Normal distribution (mean: 2, standard deviation: 
1.5) in seconds 

Maximum time for data expiration 

30 seconds 

Maximum time allotted to make decision 

90 seconds 

Data elements (model output) 

Measure 

Average time to make decision 

Sum of decision times / Total number of decisions 

Quality of decision made 

Average number of data elements used in decision 

Probability of decision error 

Number of decision errors / Total number of 
decisions 


Table 8. Data Elements for Modeling Information Flow in Decision Making. 


Data requirements for inputs and outputs were decided and held constant for all simulations. Only 
the flow of information was changed to represent the different feasible alternatives. 


4. Results 

In the As-Is system, the operators’ ability to obtain infonnation from several 
different visualization displays established a baseline for the time it takes to make a 
decision. The hypothesis was: a standardized visualization display would reduce the time 
an operator spends in obtaining the infonnation required by the decision maker when 
compared to the baseline. In other words, the time to obtain information an operator is 
responsible for via a single, standardized visualization display is less than the time to 
obtain the same information from several different systems. This affects the overall time 
to make a decision. 

Average time to make a decision was recorded and compared for each alternative. 
The decision quality was determined by how many additional non-required, but 
enhancing, data elements were part of the decision. Decision quality was recorded for 
each alternative to ensure it did not decrease. Likewise, a decision error was captured 
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indicating a decision could not be made in the maximum time allotted and a required data 
element was missing, or if an expired data element was processed. A reduction in either 
of these measures would be considered unacceptable if the lower value did not meet the 
threshold requirements of the respective MOEs. 

Although the specific results used in the alternatives analysis were for a two- 
second operator adjustment penalty, the following graphs show a range of the modeling 
results from one to three seconds with a half second interval. This was done to gain a 
better understanding of the results and evaluate how they vary as a result of operator 
performance differences based on experience levels, fatigue, or distractions. The graphs 
show how the alternatives compared to the As-Is baseline. 

Figure 30 shows a graph of the modeling results for average time to make a 
decision over this range. The results show a possible decrease of almost three seconds in 
the average time to make a decision with an experienced operator when incurring a one 
second penalty. The potential benefits continue to increase as the operator adjustment 
penalty increases. This suggests the average time to make a decision would be reduced, 
and inexperience or distraction counteracted with the reduction of displays. 
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Figure 30. Modeling Results for Average Decision Time 

A comparison of the average decision time from the As-Is to the GUN and Hybrid alternatives 
showing a decrease in average decision time using the alternatives with operators with higher 
adjustment penalties. 

Figure 31 shows a graph of the modeling results for average decision quality. The 
results show no immediate benefit in the average decision quality with an experienced 
operator when incurring a one second penalty. However, a small benefit is shown at the 
two second penalty range. Substantial benefits are achieved above the two second 
penalty range and continue to increase as the operator adjustment penalty increases. This 
suggests the average decision quality would be increased, and inexperience or distraction 
counteracted with the reduction of displays. 
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Decision Quality Increase When 
Compared to As-ls 



Figure 31. Modeling Results for Decision Quality 

A comparison of the decision quality from the As-ls to the GUN and Hybrid alternatives showing an 
increase in decision quality using the alternatives with operators with higher adjustment penalties. 


Figure 32 shows a graph of the modeling results for probability of decision error. 
The results show no immediate benefit in the probability of decision error with an 
experienced operator when incurring a one second penalty. However, a small benefit is 
shown at the two second penalty range. Substantial benefits are achieved above the two 
second penalty range and continue to increase as the operator adjustment penalty 
increases; this suggests the probability of decision error would be reduced, and 
inexperience or distraction counteracted with the reduction of displays. 
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Probability of Decision Error Decrease 
When Compared to As-ls 



1 1.5 2 2.5 3 


-GUN 

- "Hybrid 


Operator adjustment penalty (in seconds) 


Figure 32. Modeling Results for Probability of Decision Error 

A comparison of the probability of decision error from the As-ls to the GUN and Hybrid alternatives 
showing a decrease in decision error using the alternatives with operators with higher adjustment 
penalties. 

The data from the modeling results used in the alternative analysis were the 
respective values for a two second operator adjustment penalty. This penalty value was 
chosen as a result of direct operator observation during model design. Table 9 contains 
the values for the two second penalty results. 


Data Requirement (Results) 

As-ls 

Hybrid 

GUN 

Average time to make decision 

55.90 sec 

55.16 sec 

52.78 sec 

Quality of decision made 

67.16% 

70.66% 

70.06% 

Probability of decision error 

0.2567 

0.2168 

0.2171 


Table 9. Detailed Modeling Results for the Two Second Operator 
Adjustment Penalty 

Data requirement scores that were recorded from the modeling results are used for alternative 
comparisons 
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The analysis in modeling and simulation answers the third research question, 
“Can decision making quality, accuracy, and timeliness be quantified and modeled within 
unified C2 architectures?” Models of the three alternatives were created to measure 
decision quality, accuracy, and timeliness. The models allowed for variability in 
information arrival rate, operator handling time, and decision maker processing time. 
These variables made it possible to measure decision making quality within an allotted 
time and decision accuracy based on available information within a specified period. 
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IV. ARCHITECTURE ANALYSIS 


A functional decomposition was performed for the Support Sensemaking function 
of the Common C2 System. Following functional analysis, the Value System Design 
process was used to create evaluation measures addressing stakeholder requirements and 
later to be used to assess and compare performance of the alternatives. The Hybrid and 
the GUN remained as the most beneficial alternatives based on the Feasibility Screening. 
These alternatives have been created to exploit the architecture developed from 
functional decomposition and improve the Sensemaking functions by combining 
disparate and duplicative systems and improving visualization. As a result, decisions will 
be facilitated more quickly, with less error, and with higher quality. This was 
demonstrated through modeling and simulation. 

In this section, the benefits of the Hybrid and GUN architectures are discussed in 
tenns of efficiencies through training and their performance in modeling. A brief 
discussion on projected benefits that have yet to be validated is also included. The result 
is the architectural analysis recommendations. This is where it is explained why the 
GUN architecture is considered the best option to pursue based on the analysis done so 
far. This process is shown in Figure 33. 


79 



Needs 

Analysis 

Functional 

Analysis 

Value 

Analysis 


♦ ‘ 

i 

t 

* * 

A 


nrl 

4 


1 JL Jf 


__J 

■ ■1 - 

Nj 


-• 




HI 

r N 

i ^ 





Develop 

Architecture 

r 

Alternatives 

Bm. 

L. 


As-Is 

■> Hybrid 
■>GUN 


Metrics 

Traininghours 

Ops 

Maintenance 


Arch itectu re An alysis 



r -1 

GUN 


| * * A 

Architectural 

Ik f. x J? 

Analysis 


Recommendations 

\w ^ 

L._ J 



Model 
£4 Performance 


Metrics 

Timeliness 
Quality 
Accu racy 


Figure 33. Architecture Analysis Flow 

This illustrates the flow of the architecture analysis. The needs, functional, and value analyses lead 
to the development of Architecture Alternatives. The As-Is, Hybrid, and GUN are discussed in terms 
of training efficiencies and modeling performance. Finally, recommendations are given based upon 
the information gathered. 


A. ARCHITECTURE ANALYSIS LIMITATIONS 

The Hybrid and the GUN architectures were further examined using modeling 
and analysis. Because limited unclassified data exists on the As-Is C2 architecture, a 
notional process model for a typical surface combatant CIC was used for simulation. The 
model simulated user interaction with the number of displays in As-Is, Hybrid, and GUN 
architectures to see the impact of multiple displays on decision making. The results 
gathered were used to compare the two architectures against each other and the As-Is 
architecture. The MOPs related to decision quality, error, and time, were used. The 
results are discussed in the sections below. 


Another constraint of the model was the inability to model human cognition 
effectively. Major benefits are believed to be gained by facilitating human cognition 
through better organizing data, eliminating redundancy, and automatically flagging 
disparity. This is supported by research done by William Hick and Ray Hyman. Hick’s 
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Law states the time it takes to make a decision is based on the number of alternatives; by 
reducing redundancy, the number of perceived alternatives is reduced and a gain should 
be made [Card, 1983], The best way to model the benefits of better organized data on 
human cognition in a particular system is to create a prototype of that system and create 
use cases. The use cases would then be run in the As-Is state and then on the prototype of 
the new system to determine performance. 

Finally, this paper does not address Life Cycle Cost Estimates (LCCE). Cost 
estimates by analogy were considered earlier in the SEDP to estimate costs for the Hybrid 
and GUN architectures. However, this did not show promise because it became 
impossible to find a similar enough architecture to create a meaningful comparison. The 
main reasons were: the new architectures stress new centralized data and information 
storage and processing, combining all disparate information systems, the emphasis on 
processing information in universal formats, and the new interfaces that have yet to be 
defined. The C2UniArch team analyzed the training benefits. It is estimated the training 
requirements will be significantly reduced compared to the As-Is architecture. 


B. ANALYSIS OF ALTERNATIVES 

1. Model Performance 

The modeling results provide quantitative data to detennine if there are 
discernable benefits to the alternate architectures. Table 10 indicates there may be 
advantages to these alternatives. 


Attribute 

As-Is 

liniTgfiri 

GUN 

Average time to make decision 

55.90 sec 

55.16 sec 

52.78 sec 

Quality of decision made 

67.16% 

70.66% 

70.06% 

Probability of decision error 

0.2567 

0.2168 

0.2171 


Table 10. Raw Data Matrix 

The raw data matrix summarizes the model-predicted performance measures for each alternative 
using the two second operator adjustment penalty from the modeling section. For a more detailed 
discussion of these results see the Modeling and Simulation section. 
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The raw data was transformed into a utility value and charted. The utility value 
may be thought of as the amount of benefit gained by an alternative. The utility value is 
scaled from 0 to 100 to make comparisons easier. Each attribute that was investigated 
has its own function to convert the raw data to the utility score. In order to ensure the 
appropriate function was used, the three attributes were analyzed. Also stakeholders’ 
consultation and concurrence was sought for all utility curves. 

The decision quality utility function is piece-wise linear as a result of discussions 
with the stakeholders; it was decided once a reasonable decision quality (50%) was 
reached, there was a steady gain in value until 100% decision quality was reached. When 
transforming the raw data into utility values it was determined at least 50% decision 
quality must be reached. Decision quality of 50% or less was considered to be of no 
value by the stakeholders. There is no point at which the stakeholders consider there to 
be a steep change in the value of decision quality within this range. Figure 34 depicts the 
Utility for Decision Quality. 



Figure 34. Decision Quality Utility 

Decision Quality is the average score indicating the number of model data points used to make a 
decision. This graph shows the utility values. There is no utility from 0% to 50%. After 50%, the 
utility increases linearly. 
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The stakeholders also indicated decisions with less than 50% quality did not have 
a positive impact on mission accomplishment. A decision with low quality is just as 
likely to decrease the chance of mission success as to increase it. Once decision quality 
increases above 50%, value slowly accumulates. This is because the chance for 
increasing the likelihood of mission success is increasing with higher quality decisions. 

Referring to Figure 35, it can be seen that the Hybrid affords the best benefit by 
scoring the highest utility value. With decision quality, the higher values are desirable as 
more data points are involved in the decision making. The utility function used to 
calculate the utility value shows the Hybrid to have the best performance; however, under 
examination the raw data for the Hybrid and GUN are very close in value. Both the 
Hybrid and the GUN have a distinct benefit over the As-Is in decision quality. 



Figure 35. Decision Quality Utility Zoomed In 

Decision Quality is the average score indicating the number of model data points used to make a 
decision. This graph is a close-up between 60 and 75 percent to emphasize the difference between the 
alternatives. 

When transforming the raw data into utility values for decision error, it was 
determined if over 40% errors were reached, the decision based on this information could 
not be trusted and gave a zero utility value. A value of 100 is not reached until the 
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system is error free. However, even with a few errors, it is likely a good decision will 
still be reached, so a curved function was used. The As-Is clearly performs more poorly 
than the Hybrid and GUN. At 25-30% errors a steep drop off begins as suggested by the 
stakeholders. After reaching this many errors, the resulting decision will quickly lose 
reliability. 


Decision Errors are the percent of errors each alternative had during the 
simulation. The Decision Errors are again normalized and scaled to a utility value. In 
this case, the lower the raw data value, the greater the utility value score. Examining 
Figure 36, both the Hybrid and GUN score equally well in the utility value. While there 
is no clear distinction between them, they both score better than the As-Is. 



Figure 36. Decision Errors Utility 

Decision Errors is the percent of model simulation errors for each alternative. The As-Is clearly 
performs more poorly than the Hybrid and GUN. 


When transforming the raw data into utility values for decision time, it was 
decided, after considering mission threads like Cruise Missile Defense, decision making 
taking longer than 120 seconds are of no value. After 120 seconds it is very likely the 
defender will have already been hit. Decisions made in less than 60 seconds are usually 
in time and are of value. Between 60 seconds and 120 seconds there is a steep slope, 
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which represents the decision coming too late to be fully effective. In the case of Cruise 
Missile Defense, it represents a missile reaching the defender before being thwarted. 
There is a steep drop off that begins between 80 to 90 seconds because a cruise missile 
has a good chance of reaching its target by that time. 

Decision time is the average time for each alternative to come to a decision from 
the model simulation. The decision time utility value is higher when the average decision 
time is shorter. The decision time Utility, shown in Figure 37, shows no architecture 
performed significantly better than any other, however, the GUN slightly outperformed 
the other alternatives. It is important to note in some instances every second can count. 
When dealing with Cruise Missile Defense, a second could mean the difference between 
safety and loss. 


Utility for Decision Time 
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Figure 37. Decision Time Utility 

Decision Time is the average time to make a decision for each alternative. This curve is strongly 
influenced by the Cruise Missile Defense mission thread. 
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2. Model Attributes Scoring 


Another scoring criterion required prior to the completion of the Decision Matrix is 
the swing weighting for each attribute. Swing weights were used to rank and weigh the 
critical attributes against each other based on the best and worst case scenarios [Clemen 
and Reilly, 2001]. Using the raw data, the worst case scenario (“benchmark”) is 
developed by aligning the worst data point of each attribute and assigning to it a score of 
0. Then for each attribute, the benchmark is modified by ‘swinging’ the worst data point 
of that attribute to the best data point, creating a hypothetical alternative. These 
hypothetical alternatives essentially have only one critical attribute at its best; this forced 
the stakeholders to rank and rate (assign points) to alternatives or critical attributes which 
dominated their decision making process. These rates were then normalized and weights 
were calculated. The results are shown in the Table 11. 



Consequence to Compare 

Rank 

Rate 

Weight 

Benchmark 

Q=67.16%, DE=25.67%, DT=55.9s 

4 

0 

0 

Quality 

Q=70.66%, DE=25.67%, DT=55.9s 

2 

25 

0.13 

Decision Error 

Q=67.16%, DE=21.68%, DT=55.9s 

3 

75 

0.38 

Decision Time 

Q=67.16%, DE=25.67%, DT=52.78s 

1 

100 

0.50 



SUM 

200 

1.00 


Table 11. Finalized Swing Weights 

Q represents Decision Quality, DE represents Probability of Decision Error, and DT represents 
Decision Time. The Benchmark entry shows a culmination of the worst performance found in each 
category. Decision Time has a very high weight followed by Decision Quality and Decision Error 
with similar rates. 


To compare the alternatives, an overall value was required. By combining the 
Utility Function and the Swing Weights, the Raw Data Matrix was refined into a 
Decision Matrix. The Decision Matrix is shown in Table 12, and the values shown are a 
result of the Utility Value multiplied by the weights found in the Swing Weights Table. 
The product of these calculations was summed for each alternative to arrive at a total 
value score and is provided in the Decision Matrix Table. From best to worst values, 
they are: GUN 85.03%, Hybrid 84.84%, and As-Is 81.17%. 

The analysis presented here answers the fourth research question, “Does a unified 
C2 architecture improve decision quality, accuracy, and timeliness?” In this section, the 
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results for decision quality, accuracy, and timeliness were analyzed and the three 
alternatives were compared against each other. These results suggest a unified C2 
architecture improves these decision-making qualities. However, there was not a very 
large variance in the results. The last question that needed to be answered is, “Does a 
unified C2 architecture reduce training costs?” This question gives more information 
which will help differentiate between alternatives when performing architecture selection. 




Alternatives 

Evaluation Measure 

Weight 

As-Is 

Hybrid 

GUN 

Quality of Decision (%) 

0.13 

34.32 

41.32 

40.12 

Probability of Decision Error (%) 

0.38 

81.67 

88.80 

88.76 

Decision Time 

0.50 

92.51 

92.75 

93.47 

Total Value Score 

1.00 

81.17 

84.84 

85.03 


Table 12. Decision Matrix 

The weights calculated from the stakeholders input were used to calculate the attribute weights. 
These results were then multiplied by the Utility Value. The results were then summed for each 
alternative to yield the Total Value. 

3. Training Benefit Analysis 


An examination was conducted to determine if there was an added benefit with 
respect to system course training requirements for operators and maintenance for each 
alternative. This could identify cost efficiencies for each alternative. The analysis 
recognized the correlation between hours spent in training and cost; the exact 
determination of quantifiable cost was deferred for future studies. The examination 
began by looking at the As-Is architecture on board the most recent Arleigh Burke-class 
DDG, and collecting infonnation to see how much training was required for the ADS, 
GCCS, C2P, TTWCS, NFCS, and the SLQ-32. Since there are a number of C2 systems 
on board this class of ship, it was decided to scope the examination to those systems 
based on available data. 


Intensive research and the gathering of unclassified, readily available resources 
were perfonned for this examination. Manning requirements spreadsheets provided by 
PMW 150 for DDGs were used to approximate how many system operators and 
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maintenance personnel are required for specific systems onboard that particular class 
ship. The Navy Enlisted Manpower, Personnel Classification and Occupational 
Standards Volume II publication was used to research the specific systems personnel 
were slated to be trained on. The Catalog of Navy Courses (CANTRAC) was used to 
gather specific system course lengths in training hours per person required for that 
specific system. 

Assumptions were applied to multiple variants of C2 systems. For example, there 
are multiple AEGIS systems operator and maintenance courses offered. If a maintenance 
course length was not found, it was assumed that the length of the course was the same as 
similar maintenance courses. For instance, the AEGIS operator course is approximately 
sixteen days which is also the assumed length of the maintenance course for the AEGIS 
display console. 

Operator, maintenance, and combined operator and maintenance courses required 
for the most recent Arleigh Burke-class DDG ship exceed over 45,000 hours combined 
for those systems. Figure 38 represents the approximate manning requirements and 
course training hours for those systems. The left side, for example, represents operator 
training for the ADS, GCCS, and LINK. Forty- five Operations Specialists (OSs) are 
trained on the ADS system with a course length of 152 hours [DDG Manning 
Requirements 2009; CANTRAC vol. II 2009]. When including over 45 OSs trained to 
operate this console, this sums up to over 6,800 hours of AEGIS operator training for this 
platform. Six of the 45 are trained on GCCS-M with a course length of approximately 
208 hours and four of the 45 are trained on Link-11/16 (C2P) with a course length of 152 
hours [Activity Manpower Document 2009; CANTRAC vol. II 2009]. 

The center of Figure 38 represents the personnel trained to both operate and 
maintain ADS, TTWCS, NFCS, and the SLQ-32. These specific systems altogether sum 
up to over 20,000 hours of training per DDG ship. 
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Operator Training 



8,696 hrs 


Maintenance Training 


10+ EG# are trained on 
AN/SPY-ID (V) Radar 
maintenance @1043 
hrs = 10480 hrs 


4+ ITs are trained on 
the administration of 
GCCS at @ 152 hrs 
per operator = 608 hrs 


3+ ETs are trained on 
maintenance of GCCS 
at @ 656 hrs = 1968 
hrs 

4+ ETs are trained on 
Maintenance of LIIIK 
966 hrs = 3864hrs 


16,920 hrs 


20,616 hrs 


Figure 38. Operator and Maintenance Training Hours of C2 Systems 

For the As-Is architecture, the operator, maintenance, and combined training sum up to over 45,000 
training hours per Arleigh Burke-class DDG platform required for ADS, GCCS-M, C2P, TTWCS, 
NFCS, and SLQ-32. 


The right side of Figure 38 includes the approximate manning requirements and 
training hours for those specific systems. System maintenance training hours sum up to 
over 16,000 hours of the course maintenance training. 

Review of documentation enabled the identification of the number of hours 
associated with each system. This established a reference for total hours needed for each 
system. The primary challenge was to understand what parts of the curriculum covered 
similar functions between systems and how many hours were dedicated to each. The 
specific curriculum data needed to do this correlation was unavailable for some of the 
systems during this analysis. 

Each system was designed and built to meet individual mission requirements. A 
review of each system’s overlapping capabilities was accomplished. As the Venn 
diagram in Figure 39 illustrates, there are dedicated hours spent training similar 
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capabilities. For example, GCCS, ADS, and C2P provide geospatial displays and attempt 
to provide a visual representation of situational awareness. What could not be accounted 
for are the exact hours spent on those functions out of current system curriculum, but 
approximations could be made for a percentage of the course. 



Figure 39. As-Is Operator Functional Element Overlap of Training 

Training for the As-Is have some overlap in functional capability. This is a Venn diagram of the 
estimated amount of curriculum overlap for similar functional capabilities. 

In the Hybrid architecture, there are potential savings on hours spent by reducing 
the overlaps. The Hybrid architecture incorporates reduction of training hours for 
operators because of the reduced number of display systems from many to two. As 
explained in the alternative description, the Hybrid is a migration towards a single 
visualization interface, which contains all needed functionality, and also includes a 
legacy system ADS. Further research shows some program offices are already placing 
importance in the investigation of saving time for system training and easing the 
workload of operators. For example, the program office for TTWCS has placed great 
emphasis on achieving common look and feel displays across multiple Land Attack 
Systems, i.e., ADS, GCCS-M, and NFCS [Sullivan and Mauser 2004]. Investments have 
been made into new alternatives through Office of Naval Research (ONR) funded 
research to allow separation of all TTWCS Human Computer Interaction (HCI) from the 
Weapon Control System applications. This would aid in the designing of human 
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interfaces around complete warfare tasks rather than individual operator functions. In 
doing so, the operator’s view is expanded from looking through a "soda straw" to a 
"knowledge wall" [Sullivan and Mauser, 2004]. 

More than one program office may be investigating this approach in obtaining 
ways to ease the training time and workload challenges for operators. Potential training 
efficiencies that could be gained are represented in Figure 40. Some operator training 
hours would be reduced with a common display because of the reduction of functional 
overlap on a common display consoles in the CIC. For the Hybrid, the Aegis display 
functions would be maintained on the current consoles. The Hybrid would have some 
overlap and also include common visualization console covering the necessary functions 
of C2. There would be a framework that provides the common ontology, geospatial 
references, planning functions and provide standardized communications. All of the 
overlap between the various other systems would be covered in this common integrated 
display. Therefore all redundant functional elements are combined into a single training 
session. Specific mission unique capability packages could then be focused on providing 
more time dedicated to operator proficiency, instead of “buttonology” or “what the 
components of the interface are, what they do, [and] how to accomplish basic tasks.” 



Display 


System 
unique 
functions 


Figure 40. Hybrid Estimated Operator Training 

Training for the Hybrid system includes the ADS display, the Common Integrated Display, and the 
unique functions. 

Maintenance training hour’s reduction would only be recognized on the 
visualization aspect of the alternative; back-end aspects of each system would be 
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maintained. Because actual hours dedicated to a specific process could not be identified 
in the curriculum, estimations were made about overlapping training hours for the 
operator and maintenance courses. An approximation was made of a potential overlap 
reduction up to 30% while still allowing for specific mission unique capability training. 
For example, if this logic was applied to the hours outlined in Figure 38 (middle portion), 
roughly 20,616 hours could be reduced to 14,431 hours of training per platform. 

For the GUN architecture, a single interface would be used, and operator training 
would include one common integrated display. The back-end systems would not be a 
part of this architecture as the information provided by these systems would be integrated 
into a data repository for subscription. Each operator would be trained on the system 
architecture as well as its functions, for example, how to access specific information of 
importance and how to tailor displays. Other system functions would include the setup 
for collaboration and sharing information with other participants. 

Since the back-end systems would not be a part of this architecture, maintenance 
training hours would be reduced. Figure 41 depicts the reduced operator training for the 
GUN. The overall maintenance training hours would potentially decrease up to 50% to 
concentrate only on operation of this new system. Again, once trained on the basic 
framework, most training would focus on operational proficiency and specific unique 
operational capability instead of “buttonology” taking advantage of familiarity, common 
lexicon, and ontology. 



Figure 41. GUN Estimated Operator Training 

Operator training for the GUN system includes training for the Common Integrated Display and the 
system’s unique functions. 
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The analysis perfonned in this section analyzed the last research question, “Does 
a unified C2 architecture reduce training costs?” This section focused on how the new 
architectures streamlined training. The Hybrid and GUN both reduced training hours. 
As a result, a unified architecture does have the potential to reduce the cost of training. 


C. ARCHITECTURAL ANALYSIS RECOMMENDATIONS 

The estimated performance from modeling was not as expected and did not show 
great variances between the alternatives. The models used did show that the GUN and 
Hybrid architectures both outperformed the As-Is architecture. The GUN architecture 
has received the overall highest utility score of 85.03%. The Hybrid architecture 
followed the GUN and received the second highest utility score of 84.84%. The As-Is 
has received the lowest utility score of 81.17%. These results are summarized in Table 
12 . 


The cost efficiencies through training section showed how both the Hybrid and 
the GUN architectures required half the time for training operators and maintainers. This 
was demonstrated for an Arleigh Burke-class DDG as an example. In the example the 
45,000 training hours needed to train maintainers and operators would be reduced to 
approximately 22,000. This time could be used in a multitude of ways. One 
recommendation is to use some of the saved time to train operators more generally on the 
art of C2 rather than system buttonology. 

The overall utility scores of the GUN and the Hybrid architectures are very close 
and even though GUN is slightly higher, the scores are too close to make a distinction. 
However, GUN is believed to have many benefits that will be demonstrated upon further 
research. One of the reasons for this is because the GUN architecture utilized a loosely 
coupled services approach which could yield many life cycle benefits in the future. Also, 
remember the GUN will result in a 20% greater reduction in training than the Hybrid. 

The GUN architecture is believed to grant the greatest long tenn benefits. It will 
on average reduce decision time by about three seconds to 52.6 seconds, reduce decision 
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error about four percent to 22%, increase the decision quality about three percent to 70%, 
and decrease training of operators and maintainers by 50%. It will also fulfill the U.S. 
Navy’s desire to move towards a service-oriented architecture, making future upgrades 
easier. It is also expected, through prototyping and testing, the GUN will outperform the 
Hybrid in these areas. This is due to its more robust design, allowing for the data 
received to be collated and correlated more efficiently. It was also shown how the GUN 
and the Hybrid architectures achieve a reduction in training hours. 
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V. FINAL CONCLUSIONS 


A. SUMMARY 

U.S. Navy C2 decision-making quality, accuracy, and timeliness are being 
negatively impacted by the implementation of disparate systems that execute overlapping 
C2 functions. This development and deployment strategy has also resulted in high 
training costs. This report analyzes what C2 functions (focusing upon visualization 
support to sense-making) are currently employed at the surface combatant level and what, 
if any, unified visualization architectures could be defined. The analysis investigates if a 
unified architecture can improve the C2 measures of decision-making quality, accuracy, 
and timeliness while reducing training costs. 

The following sections discuss the research questions addressed by this report and 
the results for each: 

What are the functions of C2 at the surface combatant level? The Support 
Sensemaking function is the focus of this paper and is decomposed into Collate and 
Correlate, Provide Contextualization, and Share Information sub-functions. The 
visualization aspect of the Support Sensemaking function is analyzed as it relates to faster 
and higher quality decision making by generating alternative architectures and 
conducting modeling. Analysis provides definition and functions of C2 to remove 
ambiguity in the various definitions from different organizations. This paper clarifies C2 
as the commander’s ability to understand the situation, make timely decisions of the 
highest quality, and direct available resources in order to successfully execute a mission. 
Previous work done by Boyd and Brehmer is drawn upon in describing the decision 
making process loop. This research, along with U.S. Navy doctrine, provides the 
understanding necessary to decompose and synthesize the functions of C2. 

What architectures can be defined that address common requirements of 
USN C2 decision-making, specifically related to visualization? Three feasible 
architectures are defined: (1) As-Is, (2) Hybrid, and (3) Global Understanding Network 
(GUN). The As-Is is the architecture currently deployed on surface combatants. The 
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Hybrid architecture concept takes feeds from the processing systems in the As-Is 
architecture and combines the information into a unified interface layer for use on 
common displays while also maintaining some legacy interfaces. The GUN architecture 
concept accepts all of the data sources of the As-Is architecture and makes all information 
available on each operator’s display in a unified visualization architecture. 

Can decision-making quality, accuracy, and timeliness be quantified and 
modeled within unified C2 architectures? Feasible alternatives are evaluated through 
simulations and show a decrease in average decision time and average decision error 
when comparing the As-Is to the alternatives where fewer displays are used. An increase 
in average decision quality is indicated in the same comparisons. A swing weight 
technique is used to determine how the changes in the values of the attributes are 
important to the stakeholders and provides additional relevance to the raw data. The 
resulting order of preference is the GUN followed closely by Hybrid. Both solutions are 
preferred over the As-Is. 

Does a unified C2 architecture improve decision quality, accuracy, and 
timeliness? The GUN model decreased the average decision making time to 52.78 
seconds with a measured improvement of 5.6% (3.12 seconds) over the As-Is. The 
probability of decision error is decreased to 0.4163 with a measured improvement of 20% 
(0.2026). Quality of decision is increased to over 70% with a measured improvement of 
2.9%. These improvements are considered significant in time critical scenarios (less than 
90 seconds to make a decision) such as Cruise Missile Defense or Search and Rescue. 
Other missions not requiring this level of time critical evaluation do not contribute or 
validate this data and may need more fidelity in the model and simulations. 

Does a unified C2 architecture reduce training costs? The analysis estimates 
training overlap for the Hybrid could be reduced as much as 30% and for the GUN up to 
50% compared to the As-Is. Navy manpower and training documentation is evaluated to 
identify if a unified C2 architecture reduces training costs. Total student hours for a 
sample of the disparate C2 systems are tallied. Training time spent on the functions of 
C2 per system could not be ascertained, however, analysis of each of the system 
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capabilities uncovered overlaps. The alternatives demonstrate a reduction in capability 
overlaps, and as a result, infer a lower amount of hours needed to train. We believe this 
is a direct result of the newer alternatives introducing a common integrated display, and a 
C2 functionality framework providing common ontology and increase familiarity. It is 
expected that if all core functionality could be taught once, then only mission specific 
capability and decision aids need to be addressed during training. 

B. CONCLUSIONS 

The estimated performance from modeling did not show significant distinction 
between the GUN and Hybrid alternatives although, both perfonned significantly better 
than the As-Is architecture. The overall utility scores of the GUN and the Hybrid 
architectures are very close and even though GUN is slightly higher, the scores are too 
close to make a distinction. However, GUN is believed to have many benefits that will 
be demonstrated upon further research and is believed to grant the greatest long-term 
benefits. The GUN concept could also fulfill the U.S. Navy’s desire to move towards a 
service-oriented architecture, making future upgrades easier. The cost efficiencies 
through training reduction revealed the Hybrid and the GUN architectures requiring half 
the time for training operators and maintainers, which add to the benefits of these 
architectures. 

C. AREAS FOR FUTURE STUDY 

The Hybrid and the GUN architecture concepts proposed both indicate merits in 
performance over existing architectures. This report, however, only investigated a small 
subset of C2 functionality (visualization in support of sense-making). Expanding the 
functional analysis to include Collect Information, Command, and Plan will further vet 
the alternative architectures. Further development of the modeling and simulation of the 
alternatives, by the addition of cognitive reasoning and data recognition, may provide a 
more definitive choice. A full Life Cycle Cost Estimate should be performed on the 
Hybrid and the GUN to enable a thorough quantitative cost-benefit analysis along with a 
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Manpower Reduction Study (MRS). Using the results of the LCCE, MRS, and refined 
modeling and simulation, a determination can be made to develop either the Hybrid or 
the GUN. Provided the LCCE does not yield exceptionally high costs for this project, 
development of a prototype of the best candidate alternative to verify the modeling and 
simulation could proceed. 


98 



APPENDIX A: PROJECT PLAN 


1. INTRODUCTION 

1.1. PROJECT DESCRIPTION 

1.1.1. Problem Statement 

The Navy’s Command and Control (C2) strategy does not have a common 
set of C2 requirements that can be used across multiple surface ship 
platforms. There is a need to define a common set of C2 requirements to 
support the creation of a common enterprise level C2 architecture while 
considering emerging service-oriented architecture technologies. Two 
approaches considered to building this set of requirements are: defining a 
superset of requirements that can be pulled from to support a platform’s 
ability to accomplish a specific mission, and establishing the core set of 
requirements common among all platforms that can be built on. Either 
approach would define the subset of requirements that is common for 
surface ship C2 requirements. The benefit of having a defined subset of 
requirements would simplify the DoD acquisition process by minimizing the 
work needed for requirements’ definition for new platforms. This would lay 
the groundwork for a common fundamental architecture. It will also yield 
cost savings with reduced research and development requirements’ 
definition, analysis, performance based mission thread analysis, and 
operations training and support. 

1.1.2. Bounded Problem Statement 

The Navy has many different platforms, each of which makes use of a 
variety of weapons and sensors. Ideally all of the Navy’s platforms will 
have a common C2 framework. This project will concentrate on the C2 
architecture of surface combatants including DDGs, CGs, and FFGs 
(destroyers, cruisers, and frigates). Surface combatants provide a wide range 
of capabilities and participate in group operations including Carrier Strike 
Groups (CSGs), Expeditionary Strike Groups (ESGs), and Surface Action 
Groups (SAGs). Two types of missions will be analyzed: a combat mission 
and a non-fire mission. The first mission thread to be analyzed will be 
surface ship air defense. The second mission thread will focus on a typical 
search and rescue mission. These missions range from man over board to 
answering the distress call of a damaged ship. The assumption is defining a 
universal set of C2 requirements will be aided by choosing two mission 
threads that greatly differ in scope. 
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1.1.3. Project Goal 

The goal of this project is to develop a comprehensive listing of command 
and control requirements and proposed architecture for surface combatants 
which fit the mission threads. This will provide a descriptive scenario for a 
usable C2 sample set available to navy ships. Systems engineering analysis 
will examine this infonnation to identify and develop a common set of C2 
features that should be utilized for all future surface ship acquisitions. The 
nonnative scenario, the project goal, will be a bundled package of C2 
features required for all ships. 

1.1.4. Value Added 

The benefits of having a universal set of requirements include a simplified 
DoD acquisition process, decreased program cost, greater interoperability, 
accurate and intuitive communication. These benefits come from the fact 
that our project will streamline the requirements’ definition of many Navy 
platforms, and increase the Navy's performance. This project will apply 
modem systems engineering processes to analyze C2 requirements on a 
subset of US Navy ships performing critical missions. 

1.2. RISK MANAGEMENT PROCESS 

1.2.1. Risk Management 

A modified and abbreviated version of the DoD Risk management process 
outlined in the "Risk Management Guide for DoD Acquisition" will be 
utilized to deal with and analyze risk. Risk will be identified and tracked. 
Risk drivers will be identified, and risk mitigation strategies will be 
developed. All of this will be done continually throughout the project’s life 
cycle. 

The risks will be documented and tracked through a Risk Table and a Risk 
Matrix. In this approach, there are two basic risk components that will be 
used for every risk event. The first is the Likelihood that the risk will occur. 
The second is the severity of the Impact if that event happens. 

1.2.2. Current Risks and Status 

Our Project Management Team has already identified two risks. These risks 
are listed in the matrix and table below. The status of these risks will be 
presented to all stakeholders during Interim Progress Reviews (IPRs) and 
upon request. 
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Likelihood 


Near Certain 


Highly Likely 


Likely 


Unlikely 


Remote 


E 


D 


C 


B 


A 
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1 10 1 

Name 

Description 

Assigned 

Status 

Likelihood 

Impact 

Overall 

Risk 

1 

Group 

Locations 

Geographic Locations between Philadelphia and San Diego. 
Scheduling times has been difficult due to the three hour time 
difference and site locations 

Project 

Management 

Team 

Monitoring 

E, Near 
Certain 

2, Slight 

Yellow 

2 

Project 

Schedule 

Being able to stick to the Schedule that NPS has laid out for 
CAPSTONE project. Meeting all the deliverable dates for this 
project. May need to scale down on scope if schedule risk is 
elevated to red. 

Project 

Management 

Team 

Monitoring 

C, Likely 

4, Significant 

Yellow 


Tab 


e 


11: Risk Tracking Table 


1.3. ORGANIZATIONAL STRUCTURE 

Figure 1 shows the organizational structure of the team. The structure is broken 
up by physical location with a lead assigned for each location. Some of the 
members have been assigned specific tasks; however, this does not imply they 
will not be helping with other tasks. John Waxier has been assigned the overall 
lead due to the fact that Philadelphia is the larger site and this will allow him to 
meet face to face with the majority of the team members. 



Figure 1: Organizational Structure Diagram 

The following describes the responsibilities of each team role. The Leads will be 
responsible for ensuring the work is fairly distributed and encouraging people to 
attend meetings and stay on top of their work. The Recorder will be responsible 
for meeting minutes. The Editor will be responsible for formatting and 
submitting deliverables. The Scheduler will be responsible for ensuring the 
schedule is followed along with updating changes in the schedule and adding 
granularity as deadlines become closer. The Modeler will ensure all modeling is 
done correctly and lead the modeling effort. The Analyst will perform reviews of 
work along with aid in all aspects of the process. The Stakeholder Liaison will 
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leverage real world contacts in order to get stakeholder input in a variety of areas 
of interest. The TA will be responsible for maintaining our section of blackboard. 
CM (Configuration Management) will be responsible for ensuring team follows 
good CM practices such as revision tracking and archiving. Many members of 
the team will have their hands in many parts of these roles and more, however, 
they will take accountability for the roles named in the above chart. 

2. SYSTEM ENGINEERING APPROACH 

2.1. OVERVIEW 

The System Engineering Design Process (SEDP) method uses an iterative design 
approach composed of three phases: Problem Definition, Design and Analysis, 
and Decision Making. It will be the primary tool used to define the C2 
requirements and desired architectural baseline the Navy needs. An examination 
of the waterfall, classic Vee, and spiral system engineering processes was 
conducted to determine the best approach for this problem (Blanchard and 
Fabrycky, 2006, p. 30). It was detennined a modified SEDP process (Figure 2) 
derived from a combination of Sage & Armstrong's life cycle of system 
engineering and the US Military Academy system engineering approach as taught 
by the Naval Postgraduate school is the best approach (Sage and Armstrong, 
2000 ). 


SEDP Process 



Figure 2: SEDP Diagram 


103 




































































During the Problem Definition phase of SEDP, in-depth research and extensive 
analysis of C2 concepts is conducted. The Needs Analysis defines the 
environment, boundaries, and objectives. Stakeholders are identified and 
interviewed to refine requirements and produce an effective need. The effective 
need is used to guide the identification and examination of various components 
needed to accomplish the task and establish metrics to measure successful 
completion of the task. A value system design will define functional 
relationships, hierarchy, and initial measures of perfonnance used in the next 
phase. 

In the Design and Analysis phase, various alternatives are created with the ability 
to meet the effective need and perform within the desired thresholds. After 
considering various system requirements and project constraints, the alternatives 
are considered for feasibility. Qualitative and quantitative modeling and 
simulation is used to assess the complexity and performance of the alternatives. 
The metrics used in the modeling generate a raw data matrix, and are used in the 
Decision Making phase. 

In the Decision Making phase, a scoring criterion is solicited from the customers 
that assists in transforming the raw data into information used in the decision 
process. Methods for this include the Multi-Attribute Utility Theory (MAUT), 
Swing Weight Technique, and Sensitivity Analysis. These methods generate total 
value scores for each alternative. Estimated costs for procurement are considered 
with the utility scores as part of an assessment of Cost vs. Total Value. 

2.2. PROBLEM DEFINITION PHASE 
2.2.1. Needs Analysis 

In the first phase of the SEDP a Needs Analysis is performed. Stakeholders 

are interviewed in order to articulate the 
operational need in such a way as to fully understand the problem. This will 
help identify if the problem is based upon a mission thread or sets of mission 
threads that have external constraints such as doctrinal, environmental, and 
geo-political. The Needs Analysis will take into account the integrated 
architecture with Doctrine/ Organization/ Training/ Materiel/ Leadership/ 
Personnel/ Facility (DOTMLPF) information and provide a structured and 
organized approach for defining capabilities and understanding the 
underlying requirements for achieving those capabilities (Chairman of the 
Joint Chiefs of Staff Instruction 3170.OIF, 2007). While conducting the 
Needs Analysis, affordability boundaries are identified and taken into 
account. The team will utilize tools that enable an efficient approach to this 
problem, such as the development of use cases and conducting stakeholder 
analysis. The output of the Needs Analysis will be a detailed set of 
requirements and the articulation of the problem’s effective need. To ensure 
requirements are tracked and analyzed we will employ the use of traceability 
tools such as CORE. Because of geographic differences between the groups, 
we may employ a web based tool like the Requirements Collection, 
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Analysis, and Management (RCAM) developed by Space and Naval Warfare 
(SPAWAR) Systems Center for collaboration purposes. 

2.2.1.1. Stake Holder Analysis 

Three fundamental organizations will gain from the C2 architectural 
baseline description produced from this project. They can be grouped into 
those who pay for the architecture, the resource community; those who 
buy the architecture, the acquisition community; and those who use the 
architecture, the war fighter community. The team will work as a liaison 
between the three groups for the development of the baseline requirements 
and architectural delineation. Any disagreement between organizations 
will be handled by a forum, which will allow adjudication enabling each 
vested member to vote. Adjudication of issues will follow a process 
similar to the NAVAL NETWAR/FORCEnet ENTERPRISE Board of 
Directors (NNFE BoD) where representative members from each 
community will make a decision as a group to move forward. 

2.2.1.2. Resource Community 

The resource sponsor group is responsible for an identifiable collection of 
resources which comprise inputs to warfare and supporting warfare tasks 
by planning and identifying the funding for the requirements. A common 
set of C2 requirements provides a potential savings in R&D by reducing 
individual specific C2 architecture designs. For this task a representative 
from the Office of the Chief of Naval Operations (OPNAV) will be 
heavily consulted. 

• OPNAV N6F2 - Department of the Navy, Chief of Naval 
Operations Communication Networks 

• OPNAV N86 - Department of the Navy, Chief of Naval 
Operations Warfare Integration, Surface Warfare Branch. 

2.2.1.3. Acquisition Community 

The execution agents and systems commands would be responsible for the 
development and acquisition of the architectural baseline and supporting 
them once fielded. For this task the team will use representatives from the 
Program Executive Offices (PEO) and Systems Commands. This may 
include: 

• Program Executive Office, Integrated Warfare Systems-5 

• Program Executive Office, C4I 

o PMW760 Surface Combatant Integration 

• Chief of Naval Research 


105 



o Ship Systems and Engineering Research Division (Code 
331) 

o C4ISR Applications (Code 313) 

• Space and Naval Warfare Systems Command 

o 5.0 Engineering Division 
2.2.1.4. War Fighting Community 

The War Fighting community drives the requirements for the common C2 
architecture. Their tactical and operational experience is essential in 
providing data for this architecture. This in turn provides benefit back to 
the war lighter to enhance the mission execution. For this task the team 
will use representatives from the fleet. This may include: 

• U.S. Fleet Forces Command 

• Naval Network Warfare Command N6-N8 

• Expert opinion from Fleet commander representatives 


2.2.2. Value System Design 

The second logical step in the SEDP is the Value System Design. The Value 
System Design will start with defining objectives and organizing them in an 
objectives tree. The types of objectives useful for a C2 Architecture are 
compatibility, performance, reliability, quality, adaptability, cost, and 
flexibility. Types of objectives not being considered include profit, market, 
and competition based objectives (Blanchard and Fabrycky, 2006). Each of 
the objectives defined are given an objective measure. These objective 
measures are used in evaluating the effectiveness of alternative courses of 
action and ultimately measuring success or failure of the C2 architecture 
design. 

2.3. DESIGN AND ANALYSIS PHASE 
2.3.1. Alternatives Generation 

Using the defined objectives from the Value System Design, research is 
conducted to detennine if solutions or partial solutions exist. If not, further 
research is conducted to detennine feasibility of development for identified 
gaps. Candidate architectures will be analyzed using selected tools such as 
trade studies to determine those that are feasible and those that are not 
considered feasible based upon the objectives. Whole candidate alternatives 
will be considered and selected for further analysis and is used in the 
modeling step. 
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2.3.2. Model Alternative 

Alternatives that are detennined feasible will be illustrated using models 
determined to be practical for modeling a notional high-level C2 
architecture. Functions defined in the Needs Analysis are included in 
models such as IDEFO and Functional Flow Block Diagram (FFBD) and will 
show the resulting functional flow. Simulations will be run using COREsim 
and Excel as necessary to aid in the decision making process. Upon 
completion the team should have quantifiable data that can be used in the 
decision making phase. 

2.4. DECISION MAKING PHASE 

2.4.1. Alternative Scoring 

The alternatives will be ranked based on an assigned score. The score will 
be determined by taking the raw scores for each objective and its measure 
obtained in the analysis phase and converting them into a utility score. 
Methods for this include the Multi-Attribute Utility Theory (MAUT), Swing 
Weight Technique, and Sensitivity Analysis. 

2.4.2. Desired Architectural Baseline 

A presentation of alternatives with the respective derived score will be given 
to the stakeholders for the final selection of the set of requirements and the 
C2 architecture. The alternative with the highest score is considered to meet 
the defined objectives best and is therefore the recommended solution; 
however the final decision rests solely with the stakeholders. Additional 
considerations for each alternative to aid the stakeholders’ decision are 
presented with the scores and include: limiting and strategic factors, 
independent criteria, cost, and risk (Blanchard and Fabrycky, 2006). 

3. DELIVERABLES & SCHEDULE 

3.1. DELIVERABLES 

The following are the deliverables for the Capstone Project. 

Quarter #6: 

• Initial Capstone Project Report and Brief will be presented at Interim 
Progress Review one (IPR #1) at the end of the quarter December 2008 
and will focus on: 

o Project Management Plan 

o Stakeholder Analysis 

o Needs Analysis 

o Effective Need Statement 
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o Functional Analysis 
o Measures of Performance 
o Hierarchical Design 

Quarter #7: 

• An updated Capstone Project Report and Brief will be presented at IPR #2 
in March 2009 and will focus on: 

o Alternatives Generation 

o Establish Feasible Alternatives 

o Create Functional Models 

o Conduct Simulations 

o Define Quantifiable Data 

Quarter #8: 

• A Final Capstone Project Report and Brief will be presented in June 2009 

o Establish Swing Weights 
o Multi-Attribute Utility Decision Analysis 
o Sensitivity Analysis 


3.2. SCHEDULE 

This Project spans three academic quarters. A high level schedule is provided in 
Figure 3. It shows the deliverables and milestones for the Capstone Project. 

• Approval of PMP 

• PRR #1 

• IPR #2 

• Final report and brief 
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Figure 3: Project Schedule 
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APPENDIX B: ZWICKY’S MORPHOLOGICAL BOX 


System Functions: Support Sensemaking 

Collate and Correlate 

Provide 

Contextualization 

Share Information 

Human 

Human 

Human 

Yellow Sticky’s 

Paper Map 

Paper 

White Board 

Chess Board(physical rep) 

Website 

3 Ring Binder 

White Board(Drawing) 

COTS Digital sharing system 

Fuzzy Logic engine 

COTS Digital Context system 

GOTS/COTS Mixed sharing 

COTS Database 

GOTS/COTS Mixed Context system 

GOTS Militarized sharing 

Data Correlation engine 

GOTS Militarized Solution Context 
system 

Real-time Data Distribution Service 

GOTS Militarized 

Hologram 


Web Mash-ups 

Mixed Legacy (ADS) and New 
Standardized and Customizable 
Visualization 


Service Adapter 



Pre-Cogs 

Virtual Map 


Mind links 

Halo Deck 

Mind Links 

Shared Knowledge 

Shared Knowledge 

Shared Mental states 

Halo Deck 

New Standardized and Customizable 
Visualization 

Updated to share new data 

Quantum Computing 



Unique Interface Correlation Server 
(UICS) 

Remote Display System 

Radio Telephone 

Common Computing Correlates 

MIDB 

SATCOM 


Audible alerts 

LINK 16 


Visual alerts 

Semaphore 


TDBM 

Light based Semaphore 


AEGIS 

Nautical Flag 


Visualization Correlator 

OPNOTE 


Cross Domain Solutions 

Commander’s Intentions 


NGA products 

1MC 


Data Fusion 

General Quarters 


Joint Mapping TookKit 

Computer based exchange 


Google Earth 

USMTF 


ESRI ARC View 

EMAIL 


Microsoft Virtual Earth 

Website 


MIL-STD 2525 

CEC 


OpenGIS symbology 

TADIL 


NTDS symbology 



FalconView 



OpenMap 
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APPENDIX C: INTERVIEW QUESTIONNAIRE 


Problem Statement 

The Navy’s Command and Control (C2) strategy does not have a common set of C2 
requirements that can be used across multiple surface ship platforms. 

There is a need to define a common set of C2 requirements to support the creation of a 
common enterprise level C2 architecture while considering emerging service-oriented 
architecture technologies. Two approaches considered to building this set of 
requirements are: defining a superset of requirements that can be pulled from to support a 
platform’s ability to accomplish a specific operation and the core set of requirements 
common among all platforms that can be built on. Either approach would define the 
subset of requirements that is common for surface ship C2 requirements. 


Scoping and Bounding: 

We will concentrate on only surface combatants (FFG, CG, DDG, DDX, CGX) 

To keep focused, we will apply 2 mission threads to this particular problem: 

Area Missile Defense 
Search and Rescue 


1. From your community’s perspective, what are the benefits of a common set of 
requirements and a common C2 architecture aboard surface combatants? 

2. There are many definitions of C2, the Department of Defense (DoD) [1] defines 
command and control as follows. 

• The exercise of authority and direction by a properly designated 

commander over assigned and attached forces in the accomplishment of 
the mission. Command and control functions are performed through an 
arrangement of personnel, equipment, communications, facilities, and 
procedures employed by a commander in planning, directing, 
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coordinating, and controlling forces and operations in the accomplishment 
of the mission. 

But in order to create an architecture and form requirements we needed to understand 
what the functions of C2 are and establish a way to apply this to different mission 
threads. If we recognize that C2 must be understood from an organizational 
perspective and as such it refers in general to the means through which an entity (e.g., 
a military organization) functions in the world. We attempt to define C2 using the old 
definition and newer concepts to state: 

Command and control is the process and structures through which a unit 
operates. The units are made up of components, and how these components function with 
regard to planning, directing, coordinating, and controlling the accomplishment of 
combat and other mission is C2. 

We will attempt to outline and architect this process and detennine how the various 
components will function from the mission thread perspective. 

Strongly Agree O Agree O Disagree O Strongly Disagree I I 
Thoughts? 

3. Do you see any weaknesses in pursuing an architecture based on a common set of 
requirements? 

4. Would automation be needed and if so which part of the process? 

5. What information do you see as most important to C2? 

6. Is there data that is desired that is not readily available today? 
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7. For missile defense: 

8. For Search and Rescue: 

9. What areas of C2 do you see as needing the most improvements? 

Due to time constraints on this project we have attempted to come up with assumption 
that would also help bound the problem. 

Do you agree with these assumptions? 

• Assumptions 

Yes O No O All architecture work will be on the unclassified level 
Yes O No O Threats should be typical of current technology. 

Yes O No O The system does not need to encompass all aspects of 
C2. (It should include at least the common ones.) 

Some ideas of what we consider external to the system (meaning we are not 
asking to be paid for or designed as part of the system) 

Yes O No O National Assets 
Yes I I No I I Sensors 

Yes O No O Engagement elements (Fire control Radars, Weapons, 

Aircraft, etc.) 

Yes O No O We work within the existing military organizational 
hierarchal structures (not creating our own, or proposing new structure or 
doctrine for chain of command) 

Yes O No O We will be concentrating on North Korean cruise missile 
threats 
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Yes O No O Our SAR is going to be a downed aircraft. 

■ This is not a Special Forces operation. This is an international 
water US aircraft down scenario. 

Do you have any recommendation for change? 
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APPENDIX D: LIST OF MOE/MOPs 


• A2 Sensemaking 

o OBJ: Provide a concise and accurate operational assessment which 
expedites accurate Decision Making. 

■ MOE: Quality of Picture (Time Decision Making Takes). This 
measures the overall sensemaking assessment. 

■ MOP: Average change in seconds between Decision making with 
old Sensemaking output and modified output. This measures the 
time change between the old sensemaking assessments versus the 
improved or changed sensemaking assessment. 

o OBJ: Perform Sensemaking at least as quickly as it is currently being 
executed. 

■ MOE: Time of Sensemaking process. This measure provides the 
overall time decision making takes for sensemaking 

■ MOP: Average Change in seconds between old Sensemaking 
process and modified process. This measure captures the time delta 
between the legacy sensemaking processes versus the improved or 
changed sensemaking process. 

• Collate and Correlate (A21): This function collects and organizes the information 
for processing by the system. 

o OBJ: Organize your mission relevant information and make logical 
relationships between data. 

o A211 Organize Information (Collate): This sub-function starts the process 
of sorting out all of the provide information that contributing C2 systems 
provide. This sub-function determines if the collected information is 
relevant to the mission and rejects non-mission essential infonnation. 
Once complete the filtered information is made available for correlation. 
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■ A211 MOE: Ability to provide Clear and concise data: This 
measure provides the ability to concentrate on mission data. 

■ A211 MOP 1: % Redundancy properly identified: Capturing this 
data point provides a means of making sure the data collected has 
not already been provided. When done correctly this MOP will 
save the user time from going through already provided data that 
has not changed from original submission.. 

■ A211 MOP 2: % conflicting properly highlighted: When 
information is gathered it is important to show any infonnation that 
contradicts other information. This is important because 
contradicting data should be examined closely to determine the 
accuracy of the systems providing that data if they are evaluating 
the same area of interest. 

A212 Link Related Items (Correlate): This sub-function provides that 
ability for the user to make logical relationships between data and 
information being provided by the C2 systems. These relationships will 
be needed to provide a better understanding of the area of interest. 

■ A212 MOE: Ability to identify meaningful relationships: This 
measure captures how well the system is actually identifying 
relationships that are needed for the mission. 

■ A212 MOP 1: % Type I errors: This measures the ability to filter 
out false positive information. This measure is critical because it 
determines the accuracy of the system for infonnation that was 
once deemed important but the system filtered it out because it did 
not make sense given the specified mission criteria. 

■ A212 MOP 2: % Type II errors: This measures the ability to 
measure false negative infonnation. This measures the ability of 
the system to look at information that was originally classified as 
non important but reexamined it now seems relevant in the given 
mission. 



• Provide Contextualization (A22): This function puts the information in context 
and displays the information. 

o A221 Establish Knowledge of Battle Space : This sub-function is the 
beginning of creating the area of interest or battlespace. 

■ A2211 Analyze Historical Infonnation: In this sub-function any 
historical information is provided for the mission, 

• A2211 MOE: Enhance Operational Assessment based on 
Historical Information: This measures the way the current 
mission information is assisted by using historical data. 

• A2211 MOP: Accuracy of assumptions made based on this 
information (Adjustment made that was correct/Total 
Adjustments): these measures detennine if the historical 
data aided in the decision making process. 

• A2211 MOP: How many minutes-hours does it take to 
analyze: This data point capture the length of time it takes 
to analyze the historical data related to the mission. 

■ A2212 Analyze Intelligence: In this sub-function intelligent data is 
further analyzed for completeness. 

• A2212 MOE: Enhance Operational Assessment based on 
Intelligence Data: This measure captures that ability to 
incorporate the intelligence data and applying it the 
mission. 

• A2212MOP: Accuracy of assumptions made based on this 
information (Adjustment made that was correct/Total 
Adjustments): This measure determines if the intelligence 
data aided in the decision making process. 

• A2212 MOP: How many minutes-hours does it take to 
analyze: This data point captures the length of time it takes 
to analyze the intelligence data related to the mission. 
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■ A2213 Analyze Environmental Data: Provides the weather: terrain: 
lunar/solar: ocean conditions and other environmental factors 
related to the mission. 

• A2213 MOE: Enhance Operational Assessment based on 
Environmental Data: This measure captures that ability to 
incorporate the environmental data and applying it the 
mission. 

• A2213 MOP: Accuracy of assumptions made based on this 

information (Adjustment made that was correct/Total 
Adjustments): This measure determines if the 

environmental data aided in the decision making process. 

• A2213 MOP: How many minutes-hours does it take to 
analyze: This data point capture the length of time it takes 
to analyze the environmental data related to the mission. 

■ A2214 Establish Mission Specific Associations as a whole: This 
sub-function takes all the related infonnation and filters out 
relationships that are not applicable to the mission. 

• A2214 MOE: Establish relationship between disparate data 
points: This measures the ability to relate seemingly un 
relatable data in a logical manner. 

• A2214 MOP: Ratio of actual events that are related: 
Measuring how accurate the information that is presented 
as being related actually is related for a given mission. 

■ A2215 Monitor New Mission Specific information: Tracking real 
time or near real time data that may be useful to the mission. 

• A2215 MOE: Enhance Operational Assessment based on 
New Data: Measure the accuracy of tracking new data that 
relates to the mission. 

• A2215 MOP: Accuracy of new assumptions made 
(Adjustment made that was correct/Total Adjustments): 
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This measure determines if the new mission specific 
information data aided in the decision making process. 

• A2215 MOP: How many seconds does it take to make the 
adjustments: This data point capture the length of time it 
takes to analyze the new mission specific information data 
related to the mission. 

o A222 Provide Common Visualization: This function provides the 
common visual display no matter which C2 system is providing the 
information. 

■ A222 OBJ: The common visualization should have customizable 

views allowing the operator to focus on a specific location, time, 
and set of data. 

• A2221 Tailor Display: This sub-function allows the data to 
be displayed in a manner based on user preference. 

o A2221 MOE: Configure to display only relevant 
info based upon user set criteria: This measure 
captures the ability for the user to manipulate the 
display feature to assist in viewing the information 
provide related to the mission. 

o A2221 MOP 1: Average time to display relevant 
info in seconds: This measures how fast a 
manipulated display can provide the visual 
information. 

o A2221 MOP 2: Average perception of Tactical 
picture quality: Through the use of surveys 
provided to the user, feedback is captured with 
respect to the display features. 

• A2222 Provide Geospatial Reference: This provides a 
geographical reference a visual mission rehearsal. 
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o A2222 MOE: Establish orientation: This measure 


detennines if the geospatial reference is true, 
o A2222 MOP: Mean Accuracy of positional 
orientation: This measures how accurate the 
geospatial reference is with respect to missions. 

• A2223 Provide Standard Ontology for Information 

(Symbology): This allows for all the users to understand 
anything that is displayed using a common symbol no 
matter which C2 system provides the information. 

o A2223 MOE: Establish standard information 
presentation: This measures how effective 

standardizes information. 

o A2223 MOP: % of information displayed using 
proper standard: They capture the accuracy of how 
the standards are used. Are they used correctly, are 
they provided correctly from the C2 system and 
from the user. 

o A223 Alert on Pattern or Anomaly: This function will track and alert to 
any changes to mission parameters. 

■ A223 MOE: Generate alerts based upon pattern change for a set 
mission parameter: This measure captures the system alerts that are 
triggered by changes to a set of mission criteria. 

■ A223 MOP: Number of false alarms: This captures how accurate 
the function is with false alerts. 

• Share Information (A23): This function allows for mission data and information 
to be shared to other C2 systems. 

o A23 OBJ: Provide shared situational awareness by integrating 

information from various sources (sensors, emitters, reporting networks, 
plans, orders, etc.). 
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o A231 Collaborate with Participants: This sub-function captures the ability 
to share infonnation between mission participants. 

■ A231 MOE: Ability to share missions: This measure captures the 
accessibility of shared mission data. 

• A231 MOP 1: Percent of intended recipients informed: 
This measures the success rate to share mission data. 

• A231 MOP 2: Number of unintended groups informed: 
This measures the success rate to not provide mission data 
to users that do not have authorized access. 

• A231 MOE: Ability to share missions in near real time: 
This measures the ability to share real time data to 
participating mission users 

• A231 MOP: Measured in seconds: This measures how 
quicklyreal time data can be sent and shared to mission 
participants. 

o A232 Establish Authoritative R2: This function sets the reporting 
responsibility. 

■ A232 MOE: Ability to recognize decision hierarchy: This 
measures the ability for the mission approval cycle to be escalated 
to the final decision maker. 

■ A232 MOP: Percent informed: This measures the total participants 
informed of the mission decision hierarchy. 

o A233 Communicate Standardized information-. This sub-function 
provides a communication method to provide standardize information. 

■ A233 MOE: Ability to distribute standardized infonnation: This 
measures the ability to send standardize mission information. 

■ A233 MOP 1: Average Number of orders issued: This measures 
the overall average of mission orders delivered to the intended 
recipient. 
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A233 MOP 2: Percent messages displayed inaccurately: This 
measures if the message was delivered correctly. 



APPENDIX E: ACRONYM LIST 


Acronym 

Term 

ADS 

AEGIS Display System 

AIS 

Automatic Identification System 

Ao 

Operational Availability 

AOR 

Area Of Responsibility 

C2 

Command and Control 

C2UniArch 

Command and Control Unified Architecture 

C2P 

Command and Control Processor 

CANTRAC 

Catalog of Naval Training Courses 

CCRP 

Command and Control Research Program 

CDC 

Combat Direction Center 

CG 

Guided Missile Cruiser 

CIC 

Combat Information Center 

CJCSI 

Chairman of the Joint Chiefs of Staff Instruction 

COA 

Course of Action 

COP 

Common Operational Picture 

CSG 

Carrier Strike Group 

DDG 

Guided Missile Destroyer 

CMD 

Cruise Missile Defense 

DIACAP 

DoD Information Technology Security Certification and Accreditation 
Process 

DoD 

Department of Defense 

DoDD 

Department of Defense Directive 

DoDI 

Department of Defense Instruction 

DoD JCS 

Department of Defense Joint Chiefs of Staff 

DOODA 

Dynamic Observe-Orient-Decide-Act 

EFFBD 

Enhanced Functional Flow Block Diagram 

EMI 

Electro-magnetic Interference 

ESG 

Expeditionary Strike Group 

FFBD 

Functional Flow Block Diagram 

FFG 

Guided Missile Frigate 

GCCS-M 

Global Command and Control System Maritime 

GT 

Gross Tonnage 

GUN 

Global Understanding Network 

HCI 

Human Computer Interface 
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IA 

Information Assurance 

IAW 

In Accordance With 

IDEF 

Integration Definition for Function Modeling 

IP 

Interface Processor 

ITS 

Information Technology System 

JCIDS 

Joint Capabilities Integration and Development System 

JCS 

Joint Chiefs of Staffs 

JFMCC 

Joint Force Maritime Component Commander 

JICO 

Joint Information Control Officers 

JP 

Joint Publication 

LCCE 

Life Cycle Cost Estimates 

M&S 

Modeling and Simulation 

MDA 

Maritime Domain Awareness 

MIL-STD 

Military Standard 

MLDT 

Mean Logistics Delay Time 

MMT 

Mean Maintenance Time 

MOC 

Maritime Operations Center 

MOE 

Measure of Effectiveness 

MOP 

Measure of Performance 

MSSE 

Master of Science in Systems Engineering 

MTBF 

Mean Time Between Failure 

MTBM 

Mean Time Between Maintenance 

NFCS 

Naval Fires Control System 

NNWC 

Naval Net Warfare Command 

NSS 

National Security System 

ONR 

Office Of Naval Research 

OODA 

Observe-Orient-Decide-Act 

OPNAV 

Office of Naval Operations 

OS 

Operator Specialist 

OV 

Over View 

Pde 

Probability of decision error 

PEO 

Program Executive Office 

PEO C4I 

Program Executive Offices Command, Control, Communications, Computers, 
and Intelligence 

PEO IWS 

Program Executive Office Integrated Warfare Systems 

Qd 

Quality of decision 

R2 

Reporting Responsibility 

RFI 

Radio Frequency Interference 

SA 

Situational Awareness 
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SAG 

Surface Action Group 

SEDP 

System Engineering Design Process 

SOA 

Service Oriented Architecture 

SPAWAR 

Space and Naval Warfare 

TAO 

Tactical Action Officer 

TDS 

Tactical Display System 

TTWCS 

Tactical Tomahawk Weapon Control System 

UICS 

Unique Interface Correlation Server 

USCG 

NAVCEN 

United States Coast Guard Navigation Center 

USMA 

United States Military Academy 

UV 

Utility Value 

VSD 

Value System Design 
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